Re: [Idr] Early allocation request for draft-ietf-idr-segment-routing-te-policy

Hi John, Les,

On 10/6/17, 1:53 AM, "Idr on behalf of Les Ginsberg (ginsberg)"
<idr-bounces@ietf.org on behalf of ginsberg@cisco.com> wrote:

>John -
>
>Thanx for the detailed analysis.
>Inline.
>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
>> Sent: Tuesday, October 03, 2017 2:17 PM
>> To: idr@ietf.org
>> Cc: shares@ndzh.com
>> Subject: [Idr] Early allocation request for
>>draft-ietf-idr-segment-routing-te-
>> policy
>> 
>> Hi WG,
>> 
>> Over a month ago we had a request for early allocation of the code
>>points in
>> draft-ietf-idr-segment-routing-te-policy. I think that means the TBD
>>code
>> points listed in section 8.3, the Preference, Binding SID, and Segment
>>List
>> sub-TLVs, since all the rest have been properly allocated by IANA
>>already.
>> The draft appears to fulfill the requirements for early allocation,
>>with one
>> possible exception.
>> 
>> RFC 7120 says
>> 
>>    c.  The specifications of these code points must be stable; i.e., if
>>        there is a change, implementations based on the earlier and later
>>        specifications must be seamlessly interoperable.
>> 
>> On the face of it the current version of the spec fulfills this
>>requirement. I'm
>> slightly concerned that up through draft-previdi-idr-segment-routing-te-
>> policy-02, there were specific values given for
>> 
>>    o  new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute
>>       sub-TLVs":
>> 
>>          Suggested         Description            Reference
>>             Value
>>           -----------------------------------------------------
>>               6           Preference sub-TLV       This document
>>               7           Binding SID sub-TLV      This document
>>               8           Segment List sub-TLV     This document
>> 
>> These values conflict with values allocated for other uses in the IANA
>> registry. This was corrected quite some time ago, in -03 published
>>December
>> of 2016, which lists the values as "TBD" just as the current version
>>does, so
>> maybe there's no problem at all.
>> 
>> I presume that if we proceed forward with early allocation, any
>>pre-standard
>> implementations will be updated to use whatever values IANA actually
>> allocates -- which are sure not to be 6, 7 or 8 since those are already
>>in use. If
>> that's so, then fine. If not, then we may need to have a discussion
>>about
>> whether we really meet the "stability" requirement.
>> 
>[Les:] It is quite useful I think to point out this fact - but I fail to
>see how it is relevant to the early allocation decision.  Given that we
>know that these early codepoints are not available, I do not see that
>delaying early allocation helps in any way. If there are implementations
>that used these unassigned codepoints, the sooner we assign values the
>sooner these implementations can be updated to use values which will be
>interoperable - so if anything the facts argue that we should accelerate
>early allocation - not delay it.

I agree totally, we’ll achieve nothing by delaying this any longer.

Thanks,
Acee

>
>???
>
>   Les
>
>
>> This begins a one-week period for discussion of the early allocation,
>>which
>> time period may be extended if conversation warrants it. For
>>completeness,
>> here's my evaluation of the full list of RFC 7120 criteria:
>> 
>>    a.  The code points must be from a space designated as "RFC
>>        Required", "IETF Review", or "Standards Action".  Additionally,
>>        requests for early assignment of code points from a
>>        "Specification Required" registry are allowed if the
>>        specification will be published as an RFC.
>> 
>> Yes.
>> 
>>    b.  The format, semantics, processing, and other rules related to
>>        handling the protocol entities defined by the code points
>>        (henceforth called "specifications") must be adequately described
>>        in an Internet-Draft.
>> 
>> Yes.
>> 
>>    c.  The specifications of these code points must be stable; i.e., if
>>        there is a change, implementations based on the earlier and later
>>        specifications must be seamlessly interoperable.
>> 
>> Tentatively yes but see above.
>> 
>>    d.  The Working Group chairs and Area Directors (ADs) judge that
>>        there is sufficient interest in the community for early (pre-RFC)
>>        implementation and deployment, or that failure to make an early
>>        allocation might lead to contention for the code point in the
>>        field.
>> 
>> Yes.
>> 
>> Thanks,
>> 
>> --John
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr