Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 17 Dec 2012 02:27:55 +0000

A perhaps slightly different way of thinking of this is what is the value of allowing multiple ways to convey the same meaning? Given potential of representing Explicit-null as {0}, or {15; 0}, or {15; 15; 15; 15; 15; 0}, why (or why not) allow other than the first?

Note that the current text already has (epi ready) a MUST:
   Any of these values
   present as an extended special purpose label MUST be interpreted
   exactly as it would if it was presented as a special purpose label.

Please find some additional comments and initial questions on the document, hopefully these are useful:

More substantive:
2.  Questions
...
   4.  The special purpose label value of 3 (the "Implicit Null Label",
       [RFC3032]) is only used in signaling, never in the data plane.
       Could it (and should it) be used in the data plane?  If so, how
       and for what purpose?

This seems a bit tactical (or too focused of) a question, especially as compared to the other ones. It is also not related to "allocation, retirement, or extension" of special purpose labels, it concerns with one part of the use of a value allocated and used. Is this question proposing (implicitly, no pun intended) to partition the special purpose allocation in DP and CP? Similarly, there are special purpose / reserved labels that are used in the DP but not used as labels in signaling/CP specifically. E.g., RA and ELI are not used as a label value in signaling (say in a Label Mapping). Should a question be included as well?

Given than the answer (oversimplifying) says 'yes, if you write a Standards-Track RFC through the MPLS WG', why ask this at all? Status quo seems to be that an RTP should be written updating what's in RFC 3032.

2.  Questions
3.  Answers

There appears to be a Question/Answer pair missing. The currently allocated reserved label values are not sequential (http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xml). 4-6, 8-12, and 15 are unassigned. If this document extends the special purpose labels into {15; n}, where should new values allocated from? First from the non-extended original range until exhausting it? As a hard requirement? As a discussion point part of WG work?

3.1.  Extended Special Purpose MPLS Label Values
   Any of these values
   present as an extended special purpose label MUST be interpreted
   exactly as it would if it was presented as a special purpose label.
   In particular, an arbitrary string of consecutive extension labels is
   legal, and semantically equivalent to a single extension label (note
   that this string of extension labels MUST be followed by an extended
   special purpose label that is not the extension label).

What are the benefits or tradeoffs of instead saying "0-15 MUST NOT be used after 15"?

3.2.  Process for Retiring Special Purpose Labels
   b.  12 months after the RFC deprecating the label value is published,
...
   c.  24 months after the RFC that deprecated the label value was
       This document will request IANA to release the label value for
       for future use and assignment.
While I see value in deprecating a reserved label so as to not be used in further specifications and developments, what is the rational for allowing potential future reassignment of deprecated values? Given that the extended range is 20 bit - 15 which is quite large for its use, and we know how hard it is to prove a non-use, why entertain reassignment?

More editorial:

              Allocating and Retiring MPLS Reserved Labels
Should the title reflect "Special Purpose" instead of "Reserved" labels? Should the title include not only allocation and retirement, but also extension of the special purpose label space?

4.  IANA Considerations
...
   4.  Create a new registry called the "Extended Special Purpose MPLS
       Label Values" registry.  The ranges and allocation policies for
       this registry are as follows (using terminology from [RFC5226]).
       Early allocation following the policy defined in [RFC4020] is
       allowed only for those values assigned by Standards Action.

Which values are assigned by other schemes not by Standards Action? 

Thanks,

-- Carlos.

On Oct 25, 2012, at 12:58 PM, Kireeti Kompella <[email-masked]> wrote:

> Hi Adrian,
> 
> On Oct 25, 2012, at 08:36 , "Adrian Farrel" <[email-masked]> wrote:
> 
>> With regard to the (infinite) nesting, we could simply define that labels 0-15
>> MUST NOT appear after label 15 making the new registry run 16 to 1048575
> 
> While we could specify this, there are a host of ways people could do silly but innocuous things with the label stack, such as insert 52 explicit nulls, or 93 sets of ELI+EL.
> 
> This is a case where my allergy against MUSTs breaks out in full-blown, throat-closing glory … which may be an excellent reason for the suggestion :-)
> 
> Kireeti.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>