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

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

Hi All,

At present we don't have demonstrated consensus to advance the document. Other than the three authors (whose support can be assumed unless they disclaim it, as far as I'm concerned, so there's really no need for "support as co-author" statements, thanks for not sending them!) I count two people (John D and Stefano P) who unequivocally support advancement, one (Lou B) who does "but after addressing some comments" (which haven't yet been addressed) and one (Job S) who is opposed until implementation experience is documented. Xiaohu also provided a comment which I take to be a request to update the document, Randy commented on the thread but without taking a position.

Given both the number of points surfaced (primarily though not only in the extended exchange between Eric and Lou) and the small number of WG members who responded, I think we can't advance the document yet.

What follows is a wall of text (sorry) where I try to capture the open items arising from the WGLC discussion. I'd like to suggest the authors (and in some cases, WG) address these, at which point we can retry the WGLC. If it turns out meeting time is needed in Prague for discussion, that's a possibility. 

I've taken the liberty of tagging suggested action items. Individuals "(AI: Eric)", "(AI: Lou)", "(AI: Acee)" should be obvious, I've also tagged some "(AI: WG)" where it seems to me that there's a fundamental disagreement between two people (all Lou and Eric, actually) and nobody else has weighed in. If these aren't resolved by further discussion prior to the next WGLC, you can expect them to be called out in the WGLC poll at that time, so that we can at least know that people have been made aware of the issue before they express their preference for document advancement. So for these, the AI to the WG is to review the discussion, understand the issue, and chime in as you see fit.

Thanks,

--John


WGLC summary
------------

Implementations
---------------

There was a request for reporting of implementations. 
- Job Snijders created a wiki stub (thanks!) to hold implementation reports, see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations. 
- Lou Berger reported a partial implementation (https://www.ietf.org/mail-archive/web/idr/current/msg18155.html). I added a link and quote to the wiki. 
- Acee commented (https://www.ietf.org/mail-archive/web/idr/current/msg18199.html) that "Cisco is supporting Tunnel Attribute parsing and propagation as well as the TE-Policy tunnel type in an unreleased version of IOS-XR" and promised to update the wiki, but hasn't yet. Acee, if you need help with that, please let me know. (AI: Acee)
- Eric commented (https://www.ietf.org/mail-archive/web/idr/current/msg18200.html) that "Juniper also has an implementation of various parts of the draft, as needed to support the segment-routing-te-policy draft.  Some other parts of the draft have also been implemented as well."
- Stefano said (https://www.ietf.org/mail-archive/web/idr/current/msg18225.html) "this draft defines the Tunnel Encapsulation Attribute for which a new tunnel type (SR Policy) has been defined, as well as additional TLVs, by draft-previdi-idr-segment-routing-te-policy and for which we have an implementation".

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. Besides, since we do need implementation before sending the document to the IESG, we're going to need to clear this up no later than immediately following WGLC completion.

Given nobody has claimed anything other than "partial" support I think we have not heard the last of this question. Given the lack of enthusiasm for reporting implementation status, I don't feel optimistic that self-reporting will result in much detail. A volunteer to help produce a more structured implementation report would be great. If not, this will fall to the chairs to do or delegate as time allows.

Other Issues
------------

Xiaohu
------

Xiaohu commented (https://www.ietf.org/mail-archive/web/idr/current/msg18182.html) "Since the NVGRE header has a protocol field, it seems unnecessary to add the fake MAC header when encapsulating IP packets over NVGRE in the inter-subnet scenario, as described in (https://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00#page-3)." 

Eric replied (https://www.ietf.org/mail-archive/web/idr/current/msg18205.html) "The intention of section 3.2.3 (NVGRE) in the tunnel encaps draft is to provide the encapsulation information that is needed to form an NVGRE encapsulation as specified in RFC 7637.  If I'm understanding correctly, the draft cited above is an extension to or modification of RFC 7637, but was never adopted.  Am I wrong about that?". Unless Xiaohu has more to say, I'm considering the issue closed.

Lou
---

Lou Berger opened a number of issues (https://www.ietf.org/mail-archive/web/idr/current/msg18155.html). Discussion of these dominated the WGLC. I tried to follow the discussion for each and summarize below. (The below is not a complete set of quotations, just headlines.)

"1. I think this document needs to cover its impact on RF5566."

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.

"2. WRT the Encapsulation Extended Community.  I find the following rule
very hard to parse:"

There was a back-and-forth ending with a proposal from Lou (https://www.ietf.org/mail-archive/web/idr/current/msg18173.html modified by https://www.ietf.org/mail-archive/web/idr/current/msg18177.html, modified text shown):

> How about replacing the quoted paragraph with:
>  
>    An Encapsulation Extended Community MUST be included when a barebones
>    Tunnel TLV is used to identify a tunnel type. The corresponding
> barebones
>    Tunnel Encapsulation attribute MAY be omitted in this case.
> 
> BTW our implementation always includes a "barebones" Encapsulation
> Extended Community ;-)

I believe this ended with "Well we disagree." (https://www.ietf.org/mail-archive/web/idr/current/msg18195.html). The issue is open. (AI: WG)

"3. I'm not sure why the color sub-tlv is still needed. why not just use
the Color Extended Community alone?"

There was a long exchange on this with Lou taking the position that the ability to advertise multiple tunnel types in a single update represents unnecessary complexity and Eric taking the position that it's a reasonable optimization. Lou and Eric clearly understood each other's points but disagreed. Lou provided the caveat that if the mechanism is already being used then his objection is withdrawn, however nobody has said it's being used so presumably the objection stands.

The authors clearly don't believe a change is warranted, equally clearly Lou is unconvinced. The issue is open. (AI: WG)

There was a secondary point raised as part of the exchange (https://www.ietf.org/mail-archive/web/idr/current/msg18173.html), I will call this 3.a:

3.a. " If this is kept, it seems like there's some special aggregation rules
that could apply."

This ended with (https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) "Since we don't currently know what policies might be needed by a future application, we can't specify them now." As far as I can tell this issue is closed.

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

"5. Nit: the document says "This document deprecates the Encapsulation
SAFI (which has never been used)".  The use part of this statement isn't
strictly true"

This stands at Lou agreeing it's OK to leave the text as is if desired, Eric asked Lou "Was there ever a production deployment? I'm sure the IESG will ultimately grill me on this, so I would like to get the facts right." I haven't seen a response from Lou on-list. (AI: Lou)

"(new issue 6) In looking at the google doc, I was reminded of a
deficiency of  in 5512 that still exists in the wg draft.  Neither ever
define the format of the Tunnel TLV." (added in https://www.ietf.org/mail-archive/web/idr/current/msg18173.html)

Eric responded that Figure 1 covers this, Lou agreed, issue closed.