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

+1
Having code points allocated early would save early implementations from changing later on, de-allocation for drafts that didn’t make it should be quite straightforward process.

Regards,
Jeff

> On Oct 6, 2017, at 04:28, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr