Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sat, 27 February 2016 18:28 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB81B29EA for <isis-wg@ietfa.amsl.com>; Sat, 27 Feb 2016 10:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level:
X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 jlGBQJmwt9LV for <isis-wg@ietfa.amsl.com>; Sat, 27 Feb 2016 10:28:13 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547591B29E7 for <isis-wg@ietf.org>; Sat, 27 Feb 2016 10:28:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9222; q=dns/txt; s=iport; t=1456597693; x=1457807293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FO2sATjlLQPc8MCoiLQA/OIdDIvZ7BlM2BsF7ba2OOQ=; b=NOHHigOHElB1xmZyBn4K9wADR08RnrjoeKjVQH7gVY46W/hpv5cJrg9D 2oaiRhD4Pls87OlFDPiIxagCaVPI1EVlzP23+A+IBaXS+QNK11tIilNCc FjU4Pno50Retqt1lYzvU2hRt+8swMzWugFc+KXzUGwUQdMC7RgVy18ukk c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D+AQBb6dFW/4cNJK1egzpSbQa6TQENgWYXCoVyAoEsOBQBAQEBAQEBZCeEQQEBAQQBAQEaHTQLDAQCAQgRBAEBAR4JBycLFAkIAgQOBQiIFw6+EwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEOoQFCwYBhFgFlwwBhViIAoFlhESIUo5JAR4BAUKDZGqGbggXHX4BAQE
X-IronPort-AV: E=Sophos;i="5.22,510,1449532800"; d="scan'208";a="75680138"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Feb 2016 18:28:12 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1RISBih023296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 27 Feb 2016 18:28:12 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 27 Feb 2016 12:28:11 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 27 Feb 2016 12:28:11 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Hannes Gredler <hannes@gredler.at>
Thread-Topic: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
Thread-Index: AQHRKSDuT28sdMgL3ESJe3s68xYgBJ62KrQAgELBV1CAA4PWAIBDRWoAgAD5fjCAAHKIAP//pMtQ
Date: Sat, 27 Feb 2016 18:28:10 +0000
Message-ID: <623aa7aca98449d68305bb75bf9744dd@XCH-ALN-001.cisco.com>
References: <4C33F1DA-351A-4E4C-AB2D-EB9C530EBA36@chopps.org> <05BB1848-0F89-4A06-B1C6-7E955C41C9E9@chopps.org> <2d9f516b68fd4443853f512a533bd9d6@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A6046915200863514605D3@eusaamb105.ericsson.se> <1B502206DFA0C544B7A60469152008635152D9E1@eusaamb105.ericsson.se> <3741852a2e494e6ca54fd6ffe847ba14@XCH-ALN-001.cisco.com> <20160227175134.GA16059@gredler.at>
In-Reply-To: <20160227175134.GA16059@gredler.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.63.30]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/bSMlqtJhDr0ChI4jHvdd_x8Qrkw>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Feb 2016 18:28:16 -0000
Hannes - Discovery of tunnel endpoints is not what this draft is about. I am saying that I do not see that announcing tunnel capabilities is useful. Discovering tunnel endpoints obviously is useful - as is identifying endpoint addresses - but this draft will help us do neither. Les > -----Original Message----- > From: Hannes Gredler [mailto:hannes@gredler.at] > Sent: Saturday, February 27, 2016 9:52 AM > To: Les Ginsberg (ginsberg) > Cc: Uma Chunduri; Christian Hopps; isis-wg@ietf.org list > Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap > > hi les, > > <wg-chair hat off> > > On Sat, Feb 27, 2016 at 05:18:39PM +0000, Les Ginsberg (ginsberg) wrote: > | From my POV the draft currently defines how to advertise new > | information without defining why it is necessary to do so. > > agree - "discovery of tunnel endpoints" should be explicitly spelled out. > > | > | Yes, multiple tunnel types may be in use in the network - that does not > | in and of itself lead to a requirement to advertise supported tunnel > | types . In most cases, the support of a given tunnel type can be known > | today by other means. You give the example of RLFA - but today LDP > | reachability to an endpoint is something a router already knows - and > | this is the real requirement to setup an RLFA tunnel. Knowing that the > | endpoint is capable of supporting RLFA is insufficient. Further, folks > | (including you if I recall correctly) have indicated that they want > | more than just knowing RLFA capability - they also want to know what > | endpoint address to use. This logically leads to the use of admin tags > | which will not only indicate support for the tunnel type but also what > | endpoint address is preferred/required. > > guess the RLFA example refers to non-MPLS (IP-only deployments) > > | I think more thought and discussion is required before deciding that > | this is something that should be supported. And I think this needs to > | be done BEFORE this becomes a WG document as - almost without > exception > | - anything that becomes a WG document proceeds to become an RFC. > > IMO the generic ability to discover tunnel-endpoints is something desireable. > agreed that the actual use-cases should be (better) documented > somewhere (perhaps in RTGWG ?), but we can do that after WG adoption as > well. > > - or is it that you want to make a case that discovery of tunnel endpoints is > not desired at all ? > > /hannes > > | From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > | Sent: Friday, February 26, 2016 12:09 PM > | To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; > | isis-wg@ietf.org list > | Subject: RE: [Isis-wg] WG Adoption Call for > | draft-xu-isis-encapsulation-cap > | > | > | Dear Les et. al, > | > | > | Please post any further comments you might have on this document. > | > | > | -- > | > | Uma C. > | > | > | From: Isis-wg [[1]mailto:isis-wg-bounces@ietf.org] On Behalf Of Uma > | Chunduri > | Sent: Thursday, January 14, 2016 4:51 PM > | To: Les Ginsberg (ginsberg); Christian Hopps; [2]isis-wg@ietf.org list > | Subject: Re: [Isis-wg] WG Adoption Call for > | draft-xu-isis-encapsulation-cap > | > | > | Les, > | > | > | Thanks for your comments, see in line [Uma]: > | > | -- > | > | Uma C. > | > | > | From: Isis-wg [[3]mailto:isis-wg-bounces@ietf.org] On Behalf Of Les > | Ginsberg (ginsberg) > | Sent: Tuesday, January 12, 2016 5:25 PM > | To: Christian Hopps; [4]isis-wg@ietf.org list > | Subject: Re: [Isis-wg] WG Adoption Call for > | draft-xu-isis-encapsulation-cap > | > | > | Apologies for the very late response on this... > | > | > | I have a couple of concerns regarding taking on this work. > | > | > | The draft is straightforward enough in terms of the protocol extensions > | defined, but I am not at all clear on the usefulness of the information > | being advertised. The introduction to the draft discusses a variety of > | tunnel types which might be used in a network but does not offer an y > | reason why advertising the tunnel types supported is of benefit. > | > | > | [Uma]: Lot of use cases have been described where there is no > | configuration possible for all possible egress nodes at a given ingress > | node; as asymmetric connections can be made dynamically based on the > | network topology; using the tunnel capabilities or parameters of egress > | node from ingress. > | > | > | Given this information is only advertised within a single > | administrative domain it does not seem to provide any information that > | is not already known to the network operator. > | > | [Uma]: This is not about whether network operators know all the > | information but it's about if it is possible to configure/manage > | > | a. all options supported by possible egress nodes from ingress > | nodes perspective or > | > | b. one option of all "possible" egress nodes from ingress nodes > | pov. > | > | > | It also logically leads to requiring a configuration for what tunnel > | types to advertise. If this information is meant to drive automatic > | configuration of tunnels I presume that the network operator would want > | to limit what is advertised - not simply accept what the implementation > | is capable of supporting. So it seems we have simply traded one > | configuration for another. > | > | [Uma]: I don't see, we have traded any configuration here. An in-line > | ingress application/feature running as part of IS-IS ought to know > | what kind of tunnel capabilities the egress node is capable of > | accepting and associated parameters thereof for that tunnel. Network > | operator can always limit enabling capabilities that are being > | supported and capabilities that are being advertised by an egress node > | as part of ISIS through configuration. > | > | > | I would like to see more detail on this before deciding whether it is > | worth doing. > | > | > | It is clear that the information is not at all useful to IS-IS itself - > | which brings me to my second concern. This is advertising information > | that has nothing to with IS-IS. Router Capabilities is not meant to be > | used as a vehicle to advertise information not of direct use to the > | protocol. > | > | [Uma]: I am not sure why you see it is not all useful to IS-IS ; most > | of the features/applications listed in section 1 are related to ISIS > | protocols. For example RLFA- computation of PQ nodes done after > primary > | SPF and as part of RLFA SPFs (neighbor SPF, neighbors rSPF) and PQ > | nodes are computed dynamically on the current topology. It's not > | conceivable to provision an ingress node with one/all tunnel > | capabilities of egress nodes (essentially where ever this feature is > | enabled and potentially all eventually). Similarly for Spring/Bier > | nodes dynamic tunnels can be supported based on the neighboring > | non-spring/non-bier node capabilities advertised. > | > | > | In fact, the existence of a couple of exceptions to this guideline is > | what prompted the creation of GENAPP (RFC 6823) as the appropriate > | place to advertise such information. > | > | > | I would like to see further discussion of the above before deciding > | that WG adoption (which almost always indicates an intent to progress > | to RFC) is appropriate. > | > | > | Les > | > | > | > | From: Isis-wg [[5]mailto:isis-wg-bounces@ietf.org] On Behalf Of > | Christian Hopps > | Sent: Monday, November 30, 2015 11:45 PM > | To: [6]isis-wg@ietf.org list > | Subject: Re: [Isis-wg] WG Adoption Call for > | draft-xu-isis-encapsulation-cap > | > | > | [It seems due to some sneaky cut and paste error, the URL was wrong in > | the original email, I've corrected in this message] > | > | > | Hi Folks, > | The authors have requested the IS-IS WG adopt: > | > | > | > | [7]https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/ > | > | > | as a working group document. > | > | Please indicate support or no-support for taking on this work. > | Thanks, > | Chris. > | > | References > | > | 1. mailto:isis-wg-bounces@ietf.org > | 2. mailto:isis-wg@ietf.org > | 3. mailto:isis-wg-bounces@ietf.org > | 4. mailto:isis-wg@ietf.org > | 5. mailto:isis-wg-bounces@ietf.org > | 6. mailto:isis-wg@ietf.org > | 7. > | https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/ > > | _______________________________________________ > | Isis-wg mailing list > | Isis-wg@ietf.org > | https://www.ietf.org/mailman/listinfo/isis-wg
- [Isis-wg] WG Adoption Call for draft-xu-isis-enca… Christian Hopps
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Wunan (Eric)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Shah, Himanshu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Christian Hopps
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Jeff Tantsura
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Mach Chen
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… bruno.decraene
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Luay Jalil
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Hannes Gredler
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Marc Binderberger
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Hannes Gredler
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Marc Binderberger
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Philip Christian
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Hannes Gredler
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Marc Binderberger
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Marc Binderberger
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Philip Christian
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Philip Christian
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Philip Christian
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Uma Chunduri
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption Call for draft-xu-isis-… Xuxiaohu