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

["Adrian Farrel" <[e-mail]>]

Hi Eric,

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

None that I can see.

It is something that needs to be done before we run out of reserved labels. At
current rate of burn we have a decade or so.

>From my perspective, the urgency is simply that we have some people with the b/w
to sort it out today, and we haven't lost all of the original MPLS clue yet.

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

Absolutely!

Anyone who suggests inspecting every label in the stack at every hop in case one
is not recognised is certifiable :-)

There are two questions:
1. The unrecognised label shows for active processing (i.e. top of stack). Drop
packet it only option.
2. The unrecognised label shows for passive processing (e.g., hash). Just use it
as normal and move on.

If this is not clear from existing work and from this document, it should be
clearly stated in a new revision.

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

How much of what follows is just "here is another way of doing it" and how much
is "there is a really good reason for this"?

I think I see a request for any special purpose label (in this new space or in
the old space) to just use the least significant bits. Is this a hardware
implementation thing?

This cuts back to something you said in a previous mail: to process a special
purpose label, an implementation has never had to look up a 20-bit label, only a
4 bit label. This is true. But so what? To look up a special purpose label, an
implementation has never had to look up an extended special purpose label, and
we are changing that.

So I think the argument might be that processing of special purpose labels is
likely to require special hardware processing, with a sort of look-up table of
functions (a jump table?). Such hardware would benefit from a relatively
constrained set of potential label values.

Do I have that right?

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

Exactly. That's why we had to use (at least) one old space label to say "another
special label follows".
I was sure we had said this in the I-D, but can't recall.

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

I am not convinced by Jeff's argument.
Firstly, what does "look at" mean?
Secondly, by publishing this now, there is a lead time of 7 special purpose
label allocations before implementations have to be capable of this (maybe
*that* is the urgency?)

Ciao,
Adrian (as co-author)