Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Lou Berger <lberger@labn.net> Tue, 23 May 2017 16:11 UTC
Return-Path: <lberger@labn.net>
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 735B5129BB6 for <idr@ietfa.amsl.com>; Tue, 23 May 2017 09:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 e2GH09nJoWJp for <idr@ietfa.amsl.com>; Tue, 23 May 2017 09:11:45 -0700 (PDT)
Received: from gproxy4.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5701129418 for <idr@ietf.org>; Tue, 23 May 2017 09:11:42 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id E70621766C9 for <idr@ietf.org>; Tue, 23 May 2017 10:10:51 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id PsAo1v0092SSUrH01sArhK; Tue, 23 May 2017 10:10:51 -0600
X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=tJ8p9aeEuA8A:10 a=B6KMzFptAAAA:20 a=p7YFGuTEWXz_nwAk95EA:9 a=f21VQvZyLqnkhLdK:21 a=OGiMHABoWSAq-RmE:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1d943nT1k8g9WKvw2vnTzcR+P7qeeT09r4wbhWAxyCE=; b=Ryzjocn4J9YAb5/mMXA4lmNdid FE/IUelO3t7vgT7npqAHCLfyMcZrIT7HOHGOcAZtOrV0Hgdu9g2GpxECbfBnJaxHA4QRRZu41bIQ2 GWLaov7C9y4JJsU18Zuxm4gHz;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:41512 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dDCOV-0000sA-TC; Tue, 23 May 2017 10:10:47 -0600
To: Eric C Rosen <erosen@juniper.net>, "John G. Scudder" <jgs@juniper.net>
Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <c735e3fe-1b0e-23a6-78bf-7e773e605a52@juniper.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net>
From: Lou Berger <lberger@labn.net>
Message-ID: <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net>
Date: Tue, 23 May 2017 12:10:46 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dDCOV-0000sA-TC
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:41512
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nw45joixsUusbi_3BfB7TdJk6rk>
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: Tue, 23 May 2017 16:11:46 -0000
On 05/23/2017 11:04 AM, Eric C Rosen wrote: > On 5/23/2017 8:45 AM, Lou Berger wrote: >> >> On 5/22/2017 10:51 AM, Eric C Rosen wrote: >>> On 5/21/2017 3:58 PM, Lou Berger wrote: >>>> Overall I support this document being published, but after addressing >>>> some comments, most importantly the first one: >>>> >>>> 1. I think this document needs to cover its impact on RF5566. My >>>> personal preference is for this document to subsume/obsolete 5566, but >>>> the types defined in 5566 shouldn't be lost. (BTW I previously provided >>>> authors with text to allow this draft to obsolete 5566 as well, and can >>>> do so to the list if it would be helpful.) >>> It is true that this document orphans RFC 5566 by obsoleting a document >>> on which 5566 has a normative dependency. However, incorporating the >>> security-related material from 5566 in a way that makes it useful is >>> going to be a fair amount of work, and the rest of the document >>> shouldn;'t be held up waiting for that. >> Well I did make this comment ~ 2 years ago, so you shouldn't be >> surprised that I'm raising it now. I'm not saying the WG has to follow >> my preferred path (of having this doc replace 5566 as well), but I think >> something has to be done to not leave 5566 "orphaned". >> >>> If you have some simple and >>> non-controversial text to suggest, let's consider it. (I checked my old >>> emails on this topic but couldn't find it.) >> my memory is that I put together a rough google doc at the time we >> discussed whether your doc would deprecate 5512 or not. (See >> https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit) >> >> >> >> To have tunnel-encaps deprecate 5566 as well, I think the following is >> needed: >> - Include the 5566 defined tunnel types (particularly 4, 5 and 6) >> - include section 3.4.1 and 3.6 from the google doc (which is just edit >> text from 5566 sections 3 and 4) >> - perhaps include the 2nd paragraph of the Security Considerations >> section >> >> Given that the text is mostly lifted from 5566, I'd hope this qualifies >> as "simple and non-controversial". > > RFC 5566 assumes that the IPsec tunnel info and the authenticator > sub-TLV is conveyed on an update of the encapsulation SAFI. I'm not > convinced that there are no addtional security issues to be considered > if this information is carried on updates of other address families. I think the assumption is that the sub-TLVs are conveyed with the attribute. I don't see how changing the SAFI impacts this. > Also, note that in RFC 5512, the tunnels only extend to the BGP next > hop, while in the tunnel-encaps draft the tunnel endpoints are not > necessarily the BGP next hop. This might also change some of the > security properties. I think this would have to be thought out fairly > thoroughly, and I don't think that work's been done yet. So leaving 5566 as is introduces this issue already (due to the introduction of the remote endpoint sub-tlv). If the we deprecate 5566 with this document, this can be trivially addressed by saying that the endpoint Authenticator sub-tlv applies to the endpoint identified in the Remote Endpoint Sub-TLV. > Given that no one's been motivated to do the necessary work over the > past two years, I don't think the draft should be held up waiting for it. > Well the document was dormant for a time and had I realized it was coming up for LC I would have offered to do the work yet again. I guess that's part of the reason to do a LC. >> (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. Don't you think it should? >> Obviously, I do. Feel free to lift Section 3 of the google doc. > > Figure 1 is not satisfactory? Yes it is - I should have had another cup of coffee before sending the message! > >> >>>> 2. WRT the Encapsulation Extended Community. I find the following rule >>>> very hard to parse: >>>> >>>> A Tunnel Encapsulation attribute MUST NOT include a barebones >>>> Tunnel TLV. Instead of placing such a TLV in the Tunnel >>>> Encapsulation attribute attached to a particular route, the >>>> corresponding Encapsulation Extended Community MUST be >>>> attached to >>>> the route. >>>> >>>> Are you saying the extended community MUST be "barebones". If so, I >>>> agree as this matches 5512 formatting. If you want this extended >>>> community to carry sub-tlv information, then I see no backwards >>>> compatibility basis for this and don't support this. Either way, I >>>> think this rule needs to be clarified. >>> I'm not sure I understand what you are objecting to. An extended >>> community cannot carry sub-TLVs. >> Perfect. That's what I was hoping for/expecting, but I couldn't parse >> your text in a way that made sense (at least to me). I also think the >> current phasing goes beyond what some implementations do, e.g., send a >> barebones EC all the time. >> >>> A number of existing applications exist that use the Encapsulation EC to >>> specify a tunnel type, with no parameters. The above-quoted paragraph >>> attempts to encourage backwards compatibility with those applications by >>> saying that if you want to specify a single tunnel type with no >>> parameters, use the Encapsulation EC. The Tunnel Encaps attribute would >>> be used whenever the Encapsulation EC is not sufficient. >> 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 endpoint. The corresponding >> barebones >> Tunnel Encapsulation attribute MAY be omitted in this case. >> >> BTW our implementation always includes a "barebones" Encapsulation >> Extended Community ;-) > > For anyone trying to follow this thread, the Encapsulation EC was > defined in RFC5512 as a simple way to specify a tunnel whose endpoint is > the BGP next hop, and for which no encapsulation information needs to be > provided. That is, only the tunnel type is identified, and nothing is > said about how to form the encapsulation for that tunnel, how to choose > which packets go through that tunnel, etc. In the draft, a "barebones > Tunnel TLV" is defined to be a Tunnel TLV that that only specifies the > tunnel type, and hence could just as well be encoded in the > Encapsulation EC. > > I don't see how it could be correct for an implementation to always > include an Encapsulation EC. Sometimes you need to specify more than > the tunnel type in order to construct the encapsulation properly. It doesn't "hurt" to include it always and there is an implementation that does this, so why not allow it? > > I don't think your suggested text is accurate, because a barebones > Tunnel TLV does not identify a tunnel endpoint. then just s/endpoint/type > >> >>>> 3. I'm not sure why the color sub-tlv is still needed. why not just use >>>> the Color Extended Community alone? (Is there really a case where the >>>> recursive lookup in section 7 would have a different color?) >>> The color sub-TLV is per-tunnel, the color EC is per route. You could >>> have multiple tunnels to a given endpoint, each with a different color. >> okay, this works -- we solved this using multiple updates. That said, >> do you think the complexity of multiple tunnel tlvs in the same update >> is needed or really used today (vs just using multiple/per tunnel tlv >> updates)? The encap safi certainly resulted in some pretty complex code >> in order to "optimize" update sizes. It seems that this too is a >> similar trade off, and would be a good additional area of complexity >> that can be simplified. If it's not used today, I think we should >> restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV. > > The use of multiple tunnels between a pair of endpoints seems to make > sense, especially if the tunnels have different characteristics, and if > color can be used to map particular traffic flows to particular > tunnels. This is something that has not changed from RFC 5512. Note > also that even the Encapsulation EC allows multiple tunnels to be > specifiied (if they are of different types), since an EC attribute can > contain multiple instances of the same extended community. I'm not arguing it that it's not a real use case, but rather that it can be solved using other existing, albeit more verbose, mechanisms. Just like encap safi itself, if no one is using this, I think it would be better to simplify the solution and associated code. If you are already making use of this in deployed code, then I withdraw the proposed simplification. > >> If this is kept, it seems like there's some special aggregation rules >> that could apply. > > I'm not sure I understand this point. If you receive two routes, and > want to aggregate them so that you onluy need to propagate one upstream, > and the two routes have different tunnel-encaps attributes, you need > some policy to decide what to do. But that's true even if the > tunnel-encaps attribute only specifies one tunnel. > Sure, and the policy may be to merge the tlv lists. This is the kind of information I'm suggesting should be added. >... Lou
- [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