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

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

Oh well, guess I ran it past everyone.  Points still stand I hope!

William

>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>William Ivory (wivory)
>>Sent: 18 March 2013 21:25
>>To: Eric Rosen (erosen); MPLS
>>Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-
>>02
>>
>>Hi Eric,
>>
>>Given you're also at Cisco, and given this would be my first post to the IETF
>>MPLS list, I thought I'd run this past you first ... (-:  Couple of points inline...
>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>Of Eric Rosen (erosen)
>>>>Sent: 18 March 2013 18:05
>>>>To: MPLS
>>>>Subject: [mpls] comments on
>>>>draft-kompella-mpls-special-purpose-labels-02
>>>>
>>>>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.
>>>>
>>>>- 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.
>>
>>Using extended labels increases packet size.  This could cause unexpected
>>issues with MTU at pinch points in a network, and could also possibly lead to
>>faster exhaustion of hardware resources as the extra labels will need to be
>>programmed in hardware.
>>
>>>>
>>>>- "an arbitrary string of consecutive extension labels is legal, and
>>>>  semantically equivalent to a single extension label"
>>>>
>>>>  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).
>>
>>Isn't it better to allow for an arbitrary number now, rather than only allow one
>>now, then have to extend in future, and end up with devices in the network
>>supporting all 3 possible levels of support (or lack of)?
>>
>>Thanks,
>>
>>William
>>
>>>>
>>>>- 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.
>>>>
>>>>- 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.
>>>>
>>>>- 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".
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>mpls mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/mpls
>>_______________________________________________
>>mpls mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/mpls