Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
Hannes Gredler <hannes@gredler.at> Fri, 04 March 2016 09:32 UTC
Return-Path: <hannes@gredler.at>
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 415061B3584 for <isis-wg@ietfa.amsl.com>; Fri, 4 Mar 2016 01:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.737
X-Spam-Level:
X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RP_MATCHES_RCVD=-0.006] autolearn=no
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 QMY0dwSFqDTW for <isis-wg@ietfa.amsl.com>; Fri, 4 Mar 2016 01:32:30 -0800 (PST)
Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6177A1A1A76 for <isis-wg@ietf.org>; Fri, 4 Mar 2016 01:32:30 -0800 (PST)
Received: from hannes-mba.local (softdnserr [::ffff:106.51.27.105]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Fri, 04 Mar 2016 10:32:25 +0100 id 000000000332C1C2.0000000056D9562A.0000369F
To: Xuxiaohu <xuxiaohu@huawei.com>, "Les Ginsberg (ginsberg)" <ginsberg@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> <623aa7aca98449d68305bb75bf9744dd@XCH-ALN-001.cisco.com> <56D3FF65.3030601@gredler.at> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5141C1@NKGEML515-MBX.china.huawei.com>
From: Hannes Gredler <hannes@gredler.at>
Message-ID: <56D95609.6010507@gredler.at>
Date: Fri, 04 Mar 2016 10:31:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5141C1@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/nnXuU04FKqcOzxs0XPPqToNoWII>
Cc: Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org list" <isis-wg@ietf.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: Fri, 04 Mar 2016 09:32:33 -0000
that sounds sufficient to me for tunnel end-point discovery; /hannes On 2/29/16 10:06, Xuxiaohu wrote: > Hi Hannes and Les, > > The End Point sub-TLV as described in Section 5.3 is just used to indicate the tunnel endpoint address(es). > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler >> Sent: Monday, February 29, 2016 4:21 PM >> To: Les Ginsberg (ginsberg) >> Cc: isis-wg@ietf.org list; Christian Hopps >> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap >> >> hi les, >> >> On 2/27/16 19:28, Les Ginsberg (ginsberg) wrote: >>> 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. >> >> agreed - IP prefix info is missing ... >> i can see two ways to fix this: >> >> 1. explicitly state that the tunnel-encaps-cap refers to a particular >> IP prefix >> 2. move the tunnel-encaps-cap underneath an IP prefix TLV >> >> we should be good the, right ? >> >> /hannes >> >>> >>>> -----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 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