Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02

["William Ivory (wivory)" <[e-mail]>]

>> -----Original Message-----
>> From: Eric Rosen (erosen)
>> Sent: 19 March 2013 17:03
>> To: William Ivory (wivory)
>> Cc: Eric Rosen (erosen); MPLS
>> Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02
>> 
>> 
>> > Using extended labels increases packet size.  This could cause
>> > unexpected issues with MTU at pinch points in a network,
>> 
>> Suppose one has a choice between (a) reusing a deprecated codepoint from the special purpose
>> label space, and (b) using a new codepoint from the extended special purpose label space.  The
>> risk of (a) is that you later find that you have a customer with a legacy system that still uses the
>> deprecated codepoint.  The risk of (b) is that the label stack is 32 bits longer for each occurrence
>> of the label, and this is the factor that pushes some packets over the MTU.
>> 
>> IMHO, (b) is the much more cost-effective strategy.  Lower risk, and lower cost to work around it
>> if it happens.
[] 
>From my (admittedly short) experience of MPLS, MTU is a consistent problem in the field.  There's risk in both approaches, and while I'm happy if the consensus is for (b), I think the possible impact on existing network configurations should not be ignored.

>> 
>> > and could also possibly lead to faster exhaustion of hardware
>> > resources as the extra labels will need to be programmed in hardware.
>> 
>> Even if we deprecated and reused every special purpose label from the non-extended space,
>> that would only be 16 labels.  I hope that 16 labels in the extended space will not exhaust the
>> hardware resources.
[] 
16 wouldn't be a problem IMO.  Was (mistakenly) thinking it was the whole label space to consider, not just 16.

>> 
>> With regard to the issue of allowing an arbitrary number of "extension
>> labels":
>> 
>> > Isn't it better to allow for an arbitrary number now, rather than only
>> > allow one now, then have to extend in future
>> 
>> There will never be a need for an arbitrary number of extension labels, because the semantics of
>> an arbitrary number of extension labels (according to the draft) is the same as the semantics of a
>> single extension label.
>> 
>> I wonder if there is a terminological issue here.  An extended special purpose label is
>> represented by a pair of contiguous label stack entries.
>> The topmost entry of the pair is the "extension label" (label value 15), and the bottommost entry
>> of the pair is a label from the extended special purpose registry.  It should be possible to have an
>> arbitrary number of such pairs in the label stack.  But I don't see the value of having an arbitrary
>> number of contiguous "15"s followed by a label from the extended special purpose registry.
[] 
Maybe I've completely misunderstood the proposal, but isn't the idea that we have:

- [0-14][unreserved label]...
- [15][0-14 representing next 15 reserved labels][unreserved label] ...
- [15][15][0-14 representing 2nd new set of 15 reserved labels][unreserved label] ...

?

William

>> 
>> 
>>