Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02

[Eric Rosen <[e-mail]>]

Loa> However there is one (maybe two) things in the draft that is a little
Loa> more urgent than the extension of the special purpose label space.

Loa> 1. the renaming of "reserved labels" to "special purpose labels", to
Loa>    align with how IANA uses the word "reserved".

Loa> 2. The procedures to deprecate and retire special purpose labels.

What is the urgency?

Loa> if you find a special purpose label that you don't recognize you should
Loa> silently drop that packet. So a packet with an unrecognized extension
Loa> label should not get into the hashing at all.

If an unrecognized label rises to the top of the label stack, the packet
should be dropped.  However, I don't think there's any requirement for a
router to drop a packet just because there's an unrecognized special purpose
label somewhere in the stack.  So if hashing is done on the entire stack, I
think Pablo is right that labels from the extended special purpose label
space will get into the hash.

Whether that really makes any difference is another matter.  

Pablo> This will have the effect that current implementations will add
Pablo> unintended entropy when it sees these labels.

Are there specific scenarios in which packets that should stay in order can get
different special purpose labels pushed on their stacks, but cannot get
different dynamically assigned labels pushed on their stacks?

Loa> I'd really would like to allocate 0-1023 after 15 for the extended
Loa> special purpose

How about 0-63?  Or 0-255?  

If the WG were to decide that Pablo's point is valid, one could deal with it
by treating several of the currently unused special purpose labels (I think
there are nine available) as extension labels, each identifying a new 4-bit
extended special purpose label space.  That scheme would satisfy Pablo's
criteria, but would not require more than two label stack entries to
represent any of the special purpose labels.  (I guess each such label space
would have to assign 7 as the entropy label.)

I'm not advocating this scheme, but I do think it is better than using the
cardinality of a sequence of 15's to identify a particular special purpose
label space ;-)

With regard to Jeff's suggestion to just expand the special purpose label
space by several bits, I think the problem is the following.  There are
bound to be routers in the network that do not know that 17, say, is now a
special purpose label.  Such routers may bind dynamically 17 to a FEC or
tunnel.  This will add an exciting bit of unpredictability to the handling
of packets carrying that label.

Jeff> Plenty of routers exist that are unwilling to look at a label stack
Jeff> deeper than 3..5 labels.

I'm guessing that "unwilling to look at" means that the high speed memory
used to hold the packet header cannot hold more than 3 to 5 labels.  This
would only be a problem for a P router if it had to interpret (in the fast
path) an extended special purpose label and 2-4 regular labels (or a couple
of special purpose labels) in order to dispatch the packet properly.  It
might be interesting to examine such scenarios, if someone can present them
without getting overly emotional about it ;-)