Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Lou Berger <lberger@labn.net> Fri, 26 May 2017 23:15 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 31BC9129AF6 for <idr@ietfa.amsl.com>; Fri, 26 May 2017 16:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 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, URIBL_BLOCKED=0.001] autolearn=ham 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 4HLRLI2XwTlO for <idr@ietfa.amsl.com>; Fri, 26 May 2017 16:15:08 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1CF46128854 for <idr@ietf.org>; Fri, 26 May 2017 16:15:08 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id CA6D81E0D1A for <idr@ietf.org>; Fri, 26 May 2017 17:15:05 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id RBF11v0282SSUrH01BF4km; Fri, 26 May 2017 17:15:05 -0600
X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=OUXY8nFuAAAA:8 a=vEsP9ymbTI8hwHnHsIoA:9 a=xvb0awyGBXDSmEAb:21 a=QNqTX-DYy1Phx641:21 a=CjuIK1q_8ugA:10 a=cAcMbU7R10T-QSRYIcO_:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From: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=tEXrzXDV2EHLpqgLSZpNexYQUVdD9i3ylZJmKrQpMyw=; b=C2uc77fjc57aLMHjGnEUjmKOh4 tywXH+91ISm3RdOOdzQgrY/uIqRYz/PQqrWnOqklucHZxVGt6EiYjKeyQ7zd5LjyaPAPMr9YISwje G2fti/pOmGZd587asRHGepWK2;
Received: from md92336d0.tmodns.net ([208.54.35.217]:58325 helo=[IPV6:2607:fb90:1897:7343:0:32:146a:d801]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dEORh-0007g2-C3; Fri, 26 May 2017 17:15:01 -0600
From: Lou Berger <lberger@labn.net>
To: Eric C Rosen <erosen@juniper.net>, "John G. Scudder" <jgs@juniper.net>
CC: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
Date: Fri, 26 May 2017 19:14:58 -0400
Message-ID: <15c470a9d68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <0a0d62b2-a3ce-46d8-1f1c-6ed9034dd072@juniper.net>
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> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net> <0a0d62b2-a3ce-46d8-1f1c-6ed9034dd072@juniper.net>
User-Agent: AquaMail/1.9.1-360 (build: 100900101)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="us-ascii"
Content-Transfer-Encoding: 8bit
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: 208.54.35.217
X-Exim-ID: 1dEORh-0007g2-C3
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: md92336d0.tmodns.net ([IPV6:2607:fb90:1897:7343:0:32:146a:d801]) [208.54.35.217]:58325
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YGGcOtwZ2gml3cIAxIyRuxxoh34>
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, 26 May 2017 23:15:09 -0000
On May 26, 2017 12:32:05 PM Eric C Rosen <erosen@juniper.net> wrote: > On 5/25/2017 4:33 PM, Lou Berger wrote: >> 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. > > I'll be happy to add this text. > >> Allowing a choice of tunnels between a pair of endpoints should not >> require the origination of multiple routes with different NLRIs, or >> (even worse) the use of add-paths. I don't really see the merit of >> this suggestion. >>> The point is simplification for an unused use case. Is your position >>> based on theory or actual use? > > As it happens, I was just yesterday asked by an implementer whether a > receiving endpoint could advertise two tunnels and allow the > transmitting endpoint to select one, so there does seem to be an > immediate use case. > > However, I regard it as very obvious that you might want to advertise > several tunnels, along with some criteria for selecting which traffic > goes into which tunnel. There are numerous cases where this is done by > configuring the transmitting and receiving endpoints of the tunnel, so I > don't see why someone would regard the ability to signal this > information as "theoretical". > Humm it also seems obvious to define a way to advertise changes in number of tunnels and tunnel attributes without also having to re advertising all the prefixes reachable over the tunnels - let's do that too as it obviously dramatically reduces update processing. Think of it no need to advertise those thousands of prefixes just because some tunnels were added/removed, right? But wait - we did that and have now decided that the complexity of the processing isn't worth optimizing such advertisment as *in practice* it is a corner use case. So, while I agree that supporting multiple tunnels for the same prefix is a real use case, I still question if having a second "optimized" mechanism to signal the tunnel information (in multiple sub-TLVs in the same attribute) is worth the implementation overhead. Note that the " suboptimal" mechanism will still have to be supported anyway since it just falls out of the definition, and also supports different lifetimes in tunnel endpoint management. 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