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

["Acee Lindem (acee)" <[e-mail]>]

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