Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
"Acee Lindem (acee)" <acee@cisco.com> Fri, 09 June 2017 19:42 UTC
Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21E126D85; Fri, 9 Jun 2017 12:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NTSqM5Hx2Fi; Fri, 9 Jun 2017 12:42:11 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F4D128D3E; Fri, 9 Jun 2017 12:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13196; q=dns/txt; s=iport; t=1497037331; x=1498246931; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oO+0GCl72iTxyepd5z9mi9Dj2QyxfnsydK3BoxdhDn8=; b=KY7IG7z9gpOqCEPj/miSDPnjsdGMQivDidmKyKndjelb/fn9VZbqBZWv AKO1dFaUyjZoP5uE370u1/ZVviS1Xb5j/oYjAAel56twt3OcjnH7vQdnM Pr/hAM1F2OJkq+w0FnHpxifMReDw27Qq++pqDYsunVpsFGszi1OJUx950 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DiAADO+DpZ/51dJa1SChkBAQEBAQEBAQEBAQcBAQEBAYNYYjNaB4NtihincYIRIQ2FdgIagmc/GAECAQEBAQEBAWsohRkCAQMBARsGEToLEAIBCBoCJgICAiULFRACBAENBRQEihMQsHGCJotiAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4c2gyCEQgsBARuDEoJhBYlNlG8ChyaDN4higgaFQ4o9iRGLWAEfOEw+dBVIhQwcgWZ2AYcOgSOBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.39,319,1493683200"; d="scan'208";a="254001698"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2017 19:42:10 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v59Jg9vn003228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2017 19:42:10 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Jun 2017 15:42:09 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 9 Jun 2017 15:42:09 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>, "idr@ietf.org" <idr@ietf.org>
CC: "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS4UyjGinpiM26E0exWNpdWq7s9KIc7lcA
Date: Fri, 09 Jun 2017 19:42:08 +0000
Message-ID: <D560656B.B2748%acee@cisco.com>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <A01DA0DD-05C2-44F4-8809-76438172860D@juniper.net>
In-Reply-To: <A01DA0DD-05C2-44F4-8809-76438172860D@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8663CDAE0F920A4C92D3E8453436E3E0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/31kV2eYGvnN56UPoqQ7vs8xGSSM>
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2017 19:42:15 -0000
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" <idr-bounces@ietf.org on behalf of jgs@juniper.net> 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 >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr
- [Idr] Working group last call for draft-ietf-idr-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Keyur Patel
- Re: [Idr] Working group last call for draft-ietf-… guntervandeveldecc
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- [Idr] 答复: Working group last call for draft-ietf-… Xuxiaohu
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John E Drake
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Randy Bush
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] 答复: Working group last call for draft-i… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John E Drake
- Re: [Idr] Working group last call for draft-ietf-… Stefano Previdi (sprevidi)
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… John Scudder
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen