Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02

[Jeff Wheeler <[e-mail]>]

On Mon, Mar 25, 2013 at 10:06 PM, Curtis Villamizar <[e-mail]> wrote:
> The point is that currently an LSR with a smaller that 2^20 (roughly 1
> million) ILM that is table based, can insure that all label forwarded
> to it by legitimate traffic falls within its ILM table.

You expressed concern that some hardware would be unable to cope with
reserved labels 16-1023 but could cope with [15][X] and I disagree.
If Entropy Labels doesn't break this hardware, then neither will any
possible expanded reserved label scheme -- except those that make the
label stack too deep.

This draft makes the label stack deeper.  There is zero benefit to
that.  I'll respond to your other remarks below, as you've actually
argued my position for me.

> I don't think we are supposed to mention vendor products, but ...
>
> I worked closely with two chip vendors.  Both of their high end chip

This working group is basing an obviously bad design decision on the
assumption that some hardware exists that somehow could not cope with
simply expanding the reserved label range from 0-15 to 0-1023.

If these hardware makers are concerned about their products
inter-operating, then they should speak up.  It shouldn't be your
responsibility.

I argue that there are zero such chips deployed with such an
incredibly stupid design that they would, in any way, break if the
0-15 range is just made 0-Bigger.

0-Bigger is technically superior, in every way, to the 15 prefix
proposed in this draft.

If you want to do the technically inferior solution, then please
justify it.  Otherwise, let these makers of old or badly-designed
chips express their concern.

> Bad hardware is no reason to not move forward.  In 2000 there were
> plenty of routers in the field that could not forward MPLS at all.

You can't argue that "bad hardware is no reason to move forward," but
then support a bad design, like this 15 prefix before new reserved
labels; and justify it by saying there is some hardware that can't
support an extended range.

Which do you want?  Supporting the bad hardware that no one has been
able to name, and no one has even claimed exists, even without naming
it?

Or would you like a technically superior solution, which is very
simply, changing 0-15 to 0-1023 (or whatever value is agreeable.)

Making the label stack deeper for no reason is really stupid.  If you
can show some reason to do it, I am certainly willing to listen.  "Bad
hardware" that no one claims exists in the field is not a reason.

> I would like to see 15 followed by 0-15 be declared to be an error.

I disagree strongly with the 15 prefix concept.  However, if it does
keep momentum, I agree that [15][15] should be undefined behavior, and
that should be explicitly documented as undefined.  This covers
routers that don't know about 15.

-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts