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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Jeff Wheeler writes:
 
> On Fri, Mar 22, 2013 at 5:25 AM, Loa Andersson <[e-mail]> wrote:
> > Specifying is easy, implementing is harder, operating is worse!
> > Label stack processing is mostly or at least commonly in HW. You
> > would need to do a HW change of your entire network the day you introduce
> > the first router with the "grown label space", otherwise
> > treatment of labels 15 to X will be non-deterministic
>  
> Loa, can you give any example of such hardware?
>  
> I believe this draft is a huge mistake, and that mistake is probably based
> on the wrong assumption you've posted (quoted above.)
>  
> Any feature introduced by extended special-purpose labels is not going to
> be supported by routers without at least new software.  If routers exist
> that are not capable of taking additional processing steps (such as punt to
> CPU, forward as IPv4/IPv6, use entropy label) based on an arbitrary label
> value, then these routers simply will not be able to support new features.
>  They will not break.
>  
> So we're not talking about breaking anyone's deployed hardware.  At worst,
> new features might not be able to be supported.  However, I suspect vendors
> were not so fantastically stupid as to hard-wire 0..15 special action label
> range into their ASICs without making it possible to install a LFIB entry
> so arbitrary labels can also take a special action.
>  
> If there are such fantastically stupid vendors, it's probably not a good
> idea to punish everyone else for their rather obvious mistake.
>  
>  
> This adds MTU complexity and wastes bandwidth / wire-time whenever extended
> S-P labels are in use.
>  
> If you are going to make those sacrifices, I think you should be able to
> give at least one example of a router that actually forces you to do it
> this way.
>  
> -- 
> Jeff S Wheeler <[e-mail]>
> Sr Network Operator  /  Innovative Network Concepts


Many LSR use a table for the ILM.  Since the receving end specifies
which label to use in both LDP and RSVP-TE (and PW), an LSR with less
than the full 20 bits of space can be assured that all labels it will
ever see will fall within that table.

A TCAM can be used as an ILM but it is much less power efficient.  It
is though common where a TCAM is used for IP routes (or MAC lookups)
and the power is already in the power budget for that use of the chip.

If the IETF is assigning the labels and decides to put a label up high
in the number space (for example a block of experimental or vendor
assigned, which I hope to never see), then the table approach won't
work.  The existing reserved space (0-15) is well within any LSR's ILM
table size.

I'm liking Pablo's suggestion a little bit because of the small
extension to the space, except for the problem of LSR that don't know
the meaning of 15 and then misinterpret the next label (for example,
as ELI).  So I like using 15 and then a small space such as 17-1023.
The worst an LSR will do with that is hash on it, so maybe any further
labels that can't be hashed on can go into the old space.

If we assign 1,000 special purpose labels, we are going to need a lot
bigger micro-programable engine instruction spaces than we have in
some existing chips that do OAM that way.  So I think ~1000 is plenty
big enough.

Curtis