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

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

Eric,

About urgency -
I just tried say when working e.g.  IANA we would benefit from getting the terminology
right. 

About retiring special purpose labels -
We could start the retirement process  for not used labels if we have the process in place. 

I didn't say "urgent" - just that I don't want to wait, while something else is discussed. 

About number extend labels -
As I said I'm prepared to discuss and that I've a preference.

/Loa

Sent from iPAD n
On 25 mar 2013, at 15:55, Eric Rosen <[e-mail]> wrote:

> 
> 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 extensiontgi wouldn't cel
> 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 ;-)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>