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

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.

???

   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