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

[Kireeti Kompella <[e-mail]>]

Hi Eric,

On Mar 18, 2013, at 11:05 , Eric Rosen <[e-mail]> wrote:

> A few comments:
> 
> - The extended special purpose label space has about a million possible
>  values (16 - 1048559), with an allocation policy of "standards action".
>  This encourages squatting on "unofficial" codepoints while discouraging
>  the publication of non-standards-track drafts describing the use of those
>  codepoints.
> 
>  I think it would be better to have a much smaller piece of the label space
>  to be allocated under the "standards action" policy.

Okay, will reduce.  Question is, what to do with the rest of the label space: make reserved, or FCFS (or both)?  If FCFS, how big?

> - With a large extended special purpose label space, why do we need a
>  process for reusing deprecated (non-extended) special purpose label
>  values?  Especially when we already know that "IETF-wide surveys" don't
>  necessarily determine correctly whether some feature is actually in use
>  somewhere.

Added the following.  (See below too.)

3.2.  Process for Retiring Special Purpose Labels

   While the following process is defined for the sake of completeness,
   note that retiring special purpose labels is difficult.  It is
   recommended that this process be used sparingly.

   a.  A label value that has been assigned from the "Special Purpose
       MPLS Label Values" may be deprecated by IETF consensus with
(etc.)

> - "an arbitrary string of consecutive extension labels is legal, and
>  semantically equivalent to a single extension label"

Gone.

>  I don't see the sense of this.  It will only lead to interoperability
>  issues when some implementation puts in lots of extraneous labels and some
>  other implementation can't handle it properly (as mentioned in the
>  Security Considerations).
> 
> - Section 3, point 4, on the possible use of codepoint 3, doesn't seem to
>  make any change to existing process or usage.  I'm not sure why it is even
>  in the document.

Will remove.  Both deprecation above and using 3 in the data plane were in response to a comment that non-extended special purpose labels were a precious commodity, even with the extended space (packet processing cycles, etc.).

> - The fact that every special purpose label has a corresponding extended
>  special purpose label seems problematic to me.  Suppose some
>  implementation decides that when it needs to push "IPv4 explicit null" on
>  a packet, it is always going to use the extended special purpose label.
>  This seems perfectly legal, but will not interoperate with other
>  implementations that understand "IPv4 explicit null" but that don't
>  support the extended special purpose label space.

Reworded thus:

	    For now, the use of the "implicit null label" (label 3) in
	    the data plane will not be allowed.  If this decision is
	    revisited later, an accompanying Standards Track RFC that
	    details the use of the label, a discussion of possible
	    sources of confusion between signaling and data plane, and
	    mitigation thereof.

and

	  Values 0-6 and 8-15 of the extended special purpose label
	  registry are set aside as reserved; these MUST NOT appear in
	  the data plane.  Label 7 (when received) retains its meaning as
	  ELI whether a regular or an extended special purpose label;
	  however, an implementation SHOULD NOT insert a label of 7 as
	  an extended special purpose label, preferring instead to
	  send 7 as a regular special purpose label.


> - From section 3.1:
> 
>       An extension label MUST be followed by another label L (and thus
>       MUST have the bottom-of-stack bit clear).  L MUST be interpreted
>       as an "extended special purpose label" from a new registry
>       created by this document (see Section 5).  Whether or not L has
>       the bottom-of-stack bit set depends on whether other labels
>       follow L. Only L is interpreted as an extended special purpose
>       label; labels following L are interpreted as normal.
> 
>  If all labels following a special purpose label "are interpreted as
>  normal", it follows that there can only be one special purpose label in
>  the stack.  I don't think that's the intention.
> 
>  Probably the final sentence should be "an extension label only affects the
>  interpretation of the label immediately below it".

That was the intent.  Reworded thus:

	  An extension label MUST be followed by another label L (and
	  thus MUST have the bottom-of-stack bit clear).  L MUST be
	  interpreted as an "extended special purpose label" and
	  interpreted as defined in a new registry created by this
	  document (see <xref target='IANA'/>).  Whether or not L has
	  the bottom-of-stack bit set depends on whether other labels
	  follow L.  The extension label only assigns special meaning
	  to L.  A label after L (if any) is parsed as usual, and thus
	  may be a regular label, a special purpose label or (if
	  prefixed by another extension label) an extended special
	  purpose label.

Kireeti.

> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls