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

[Loa Andersson <[e-mail]>]

Adrian and Eric,

On 2013-05-31 05:32, Adrian Farrel wrote:
> 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.

Maybe "urgency" was the wrong word :) .

What I meant was that I want to be able to fix up the IANA registries
so that our RFC and IDs use the terminology as the registries. We can
do that now without having decided exactly on the the size and semantics
of the extended purpose labels.

Also retiring labels is something we can do already now - as soon as
we agree on procedures.

That has nothing to do with that the original special purpose
expires or not, it mostly how we keep our IANA registries nice and tidy.

/Loa
>
> 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)
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]