Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

[Eric C Rosen <[e-mail]>]

On 6/9/2017 2:16 PM, John G. Scudder wrote:
> "4. In section 12.4, values should be defined by this document of the
> newly established Tunnel Encapsulation Attribute Sub-TLVs registry."
>
> Back-and-forth, agreement to defer. FWIW, I concur that it's fine to specify values inline for a new registry (this is not OK for existing registries of course), although it's also acceptable to wait and have IANA do it if there's no pressing need.

As it happens, the "Tunnel Encapsulation Attribute Sub-TLVs" registry is 
an existing registry, created by RFC 5512.  The draft does propose to 
change the registration policy by distinguishing several codepoint ranges.

To support the ongoing implementations and deployments, we need a 
codepoint for the following sub-TLV: Remote Endpoint.

To support the ongoing implementations and deployments of 
draft-previdi-idr-segment-routing-te-policy, we need codepoints from the 
same registry for the following sub-TLVs: Preference, Binding SID, and 
Segment List.  These codepoints need to accord with the proposed new 
registration codepoint ranges.

I suppose I could ask for early allocation of "Remote Endpoint", but 
what would really solve the codepoint allocation problem is early 
revision of the registration policy.

I thought about pulling out Section 12.4 (discussing the Tunnel 
Encapsulation Registry Sub-TLVs registry) into a separate draft, but I'm 
not sure the WG would support even that at the current time. Any 
thoughts on that?

The only other feasible option is to form an implementor's agreement, do 
self-allocation, and record the self-allocated values in the draft.  I 
prefer not to do that, but I will if there is no other option that 
enables us to move forward in a timely manner.

> After quite a long discussion, Eric agreed (https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) to add the following, proposed by Lou:
>
>> How about something adding something like the following to section 1
>>
>>    RFC5566 uses the mechanisms defined in RFC5512, while this document replaces RFC5512
>>    it does not address how the tunnel types defined in RFC5566 can be used with SAFIs other
>>    than the Encapsulation SAFI.

The following section has been added for the next revision:
----------
1.4.  Impact on RFC 5566

    [RFC5566] uses the mechanisms defined in [RFC5512].  While this
    document obsoletes [RFC5512], it does not address the issue of how to
    use the mechanisms of [RFC5566] without also using the Encapsulation
    SAFI.  Those issues are considered to be outside the scope of this
    document.
----------

> As Job correctly observed, IDR tradition doesn't strictly require implementations in order to complete WGLC, but it's perfectly reasonable for WG participants to predicate their support on implementation.

That's why LC was not requested for this draft (which has  been around 
for a couple of years, I think) until implementations were well underway ;-)

> lack of enthusiasm for reporting implementation status

Sorry, too busy expanding acronyms and double-checking the 
capitalization of the RFC2119 terms ;-)

> nobody has claimed anything other than "partial" support

The whole point is to provide some structure for passing around 
information used to build tunnels.  This eliminates the need for every 
new application to invent ad hoc mechanisms to handle what they take to 
be their immediate tunneling needs.  When someone implements a 
particular application, they would be expected to implement only as much 
of this draft as is needed to support that application.  Someone who 
doesn't, for example, support NVGRE encapsulation, would be unlikely to 
implement the NVGRE encapsulation sub-TLV.  If a need for NVGRE is later 
discovered, it's helpful to have some existing structure with a place to 
hook it in.