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

[Eric Rosen <[e-mail]>]

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.