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

[John Scudder <[e-mail]>]

Thanks, Acee. However, let's plan to do another WGLC when the open items have been addressed. At minimum there is an update needed for the agreed change. 

I don't see any reason a long time has to elapse before we do the repeat WGLC, but this one is now closed. 

--John 

> On Jun 9, 2017, at 3:42 PM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Hi John, 
> 
> As the owner an AI, I support publication as well.
> 
> Thanks,
> Acee 
> 
> On 6/9/17, 2:16 PM, "Idr on behalf of John G. Scudder"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
>> 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%20impleme
>> ntations. 
>> - 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.
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>