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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 May 2013 04:32:02 +0100

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)

---

From: Loa Andersson <[email-masked]>
Date: Fri, 31 May 2013 10:33:58 +0200

Adrian and Eric,

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

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Eric Rosen <[email-masked]>
Date: Fri, 31 May 2013 10:50:23 -0400

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

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

Adrian> Do I have that right?

I don't want to make predictions about how hardware will be built in the
future.  However, I don't see any possible benefit to requiring the hardware
to do a 20-bit lookup when we only expect to see a small number of
codepoints (certainly less than 100) assigned.  Keep the special purpose
label values in the low order octet and let the hardware designers decide
whether a full 20-bit lookup is the most cost-effective way to build the
hardware.

Another perspective: the WG might at some later time decide to use the
higher order bits for something else.

Eric> So if hashing is done on the entire stack, I think Pablo is right that
Eric> labels from the extended special purpose label space will get into the
Eric> hash.

Adrian> [If the] unrecognised label shows for passive processing (e.g.,
Adrian> hash). Just use it as normal and move on.

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

This would put the draft at odds with RFC 6790, which says "reserved labels
MUST NOT be used as keys for the load-balancing function".  I can't tell
whether the draft intends to update RFC 6790, because the "Updates:" line is
truncated by the name of one of the authors ;-)

Adrian> I am not convinced by Jeff's argument ... by publishing this now,
Adrian> there is a lead time of 7 special purpose label allocations before
Adrian> implementations have to be capable of this

Now I'm quite confused about your position.  Xiaohu stated:

Xiaohu> how about explicitly stating that the Extended special purpose
Xiaohu> labels SHOULD NOT be allocated by IANA until the regular special
Xiaohu> purpose label space (0-14) has been almost used out 

You replied:

Adrian> I note that the regular special purpose label space (0-14)
Adrian> *is*already* almost used out.  Thus, making the statement would have
Adrian> no effect because we are already passed the point. 

Are you now saying that you've changed your mind?  And that you disagree
with Stewart's position:

Stewart> That would suggest that we prefer to allocate from the new range
Stewart> and keep the old range for critical new functions that really are
Stewart> stack size sensitive.

I tend to agree with Xiaohu (and thus disagree with the positions taken by
Stewart and Loa).  The new range is not useful until hardware/firmware
support for it is ubiquitous, so I don't see how we can begin using it any
time soon.  Strictly speaking though, this is not an issue for IANA, because
it is up to the WG to specify the registry from which an allocation is
requested.