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

[Curtis Villamizar <[e-mail]>]

In message <CAPWAtbLw0vHDMO28LqNpBY93FtWFSz0eWxNjo=[e-mail]>
Jeff Wheeler writes:
 
> 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.

You are obviously not getting what is being proposed.  Please start by
more carefully reading draft-kompella-mpls-special-purpose-labels-02

   An extension label MUST be followed by another label L (and thus
   MUST have the bottom-of-stack bit clear).  L MUST be interpreted as
   an "extended special purpose label" from a new registry created by
   this document (see Section 5).  Whether or not L has the
   bottom-of-stack bit set depends on whether other labels follow
   L. Only L is interpreted as an extended special purpose label;
   labels following L are interpreted as normal.

All I'm suggesting to change this is that we restrict L to be in the
range 16-1023 rather than use the whole 20 bit range.

No one at all it proposing just increasing the range from 0-15 to
0-1023.  I hope that is now clear.

If the LSR can't handle any new extension and 15+L is on top of stack,
it will barf (drop packet) either on the 15 (doesn't support
extensions at all) or barf on L (doesn't support that extension).  Any
extension has to state in the RFC how this is avoided (for example,
RFC6790 has a negociation between ingress and egress that prevents an
egress having to POP an ELI and EL if it doesn't support that aspect
of RFC6790 forwarding.

The other concern is hashing for multipath.  If the LSR doesn't handle
ELI (and even if it does since RFC6790 says SHOULD in this case), it
could hash on the EL (and maybe even the ELI) and keep going.  Also if
it doesn't know about the "extension label" then it will hash on L and
may even hash on the 15.  Any proposals to use the extension label (or
any existing special purpose label aka reserved label) needs to also
consider this backwards compatibility issue.

Any provider making use of extensions must consider what is written
about backwards compatibility in the RFC that define the extension and
then also consider what their existing installed base of LSR will do.
The provider always has the option to disable any new extension that
would have bad effects due to older LSR in their network and all they
lose is the potential benefit of the extension.

> 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.

See above.

> > 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.)

The reason we should not extend the range is that the values 16-1023
can still be used as forwarding labels if they are not followed by 15.
Older LSR would commonly request labels starting with 16 and up making
the simple range extension highly problematic.

If something like GAL is proposed, then an upgraded LSR could
potentially send a special purpose label to an older LSR that is using
that label as a forwarding label.

> 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.

But we are making it one deeper for a good reason and only when/if
some future, yet to be defined extensions use the 15+L extension
mechanism.  At that time the WG can decide whether backwards
compatibility is sufficiently considered and a network operator can
decide whether to deploy it given their installed base.

For many existing hardware designs, the ability to skip 0-15 in the
hash is quite easy to implement, if they don't already to that.
Skipping 15+L is not that much harder to do.  A lot of chips today
have full access to the first 256 bytes anywhere in the pipeline and
can skip a few (same as they can skip an entire header).  Some of the
hashing engines are very limited and this will have to be considered
in the backwards compatibility section of any RFC defining an
extension, whether using the 0-14 range or using 15+L.

> > 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

Curtis