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

["John G. Scudder" <[e-mail]>]

On Jun 13, 2017, at 1:23 PM, Eric Rosen <[e-mail]> wrote:
> 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.

Thanks for clarifying this; I was relying on the content of the email exchange and hadn't checked the registry existence myself. Sorry for the noise.

> 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?

Of course I can't say whether the WG would support it or not, although it seems to me that given the WG adopted the tunnel-encaps doc as a whole it wouldn't be unreasonable to adopt it piecemeal too. Of course there are points that could be raised pro or con.

It seems to me that given tunnel-encaps is (I hope) near the end of its journey, the time required to extract, adopt, and progress 12.4 independently would probably not be time well spent. It might possibly progress a bit before tunnel-encaps since it would be an administrative document and not be held up by most of the things that could snag tunnel-encaps; then again, as you well know there's overhead in moving even the simplest document. Since I'm still optimistic that tunnel-encaps can be moved relatively soon, my instinct would be to stay the course. I don't insist, though.

> 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.

Unsurprisingly, I would like to discourage you from doing that. I would much rather the option of progressing 12.4 as an independent 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.

Sure. I guess your point here is that almost any implementation will be "partial". That's fine. I think this means the implementation report will have to have at least a little structure to it, more than currently exists in the wiki. I don't think this needs to be controversial, but it does mean someone has to invest a few hours in structuring the report, and various other people have to invest minutes-to-hours populating it.

Thanks,

--John