IETF Logo Mail Archive

Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Uma Chunduri <uma.chunduri@ericsson.com> Fri, 26 February 2016 20:08 UTC

Return-Path: <uma.chunduri@ericsson.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 DC1A71B2F9D for <isis-wg@ietfa.amsl.com>; Fri, 26 Feb 2016 12:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 IyrHjHNPQLV8 for <isis-wg@ietfa.amsl.com>; Fri, 26 Feb 2016 12:08:41 -0800 (PST)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1911B2F9B for <isis-wg@ietf.org>; Fri, 26 Feb 2016 12:08:41 -0800 (PST)
X-AuditID: c618062d-f79dd6d000003091-95-56d0ac8161bd
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 5E.43.12433.18CA0D65; Fri, 26 Feb 2016 20:50:25 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 15:08:40 -0500
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Uma Chunduri <uma.chunduri@ericsson.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
Thread-Index: AQHRKSDrA8JFzobLS0+ZndjUGF5XpZ62GfEAgEMqEQCAArqBAIBDUWSg
Date: Fri, 26 Feb 2016 20:08:40 +0000
Message-ID: <1B502206DFA0C544B7A60469152008635152D9E1@eusaamb105.ericsson.se>
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>
In-Reply-To: <1B502206DFA0C544B7A6046915200863514605D3@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008635152D9E1eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPiG7jmgthBn+6rCymbT7IbLHhz0Z2 i6OH3rM6MHvcu7uYyWPK742sHkuW/GQKYI7isklJzcksSy3St0vgyjjayVrwcDtjRePtz2wN jI2LGLsYOTkkBEwkZi57yQJhi0lcuLeerYuRi0NI4AijxM+TaxghnOWMEqeu7GQCqWIT0JP4 OPUnO0hCRGAjo8T+pxPB2oUFvCU2X54B1M4BlPCReLRWFiQsIuAmcffwTzYQm0VAVeLvjpms IDavgK/EgpP/2EFsIYEPjBIHrpqC2JwCfhKzf88Gq2EEuuj7qTVge5kFxCVuPZnPBHGpgMSS PeeZIWxRiZeP/7FC2EoSk5aeY4Woz5dYfesYE8QuQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW 7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxQU5uelGBpsYgVF1TIJNdwfj/emehxgFOBiV eHg/fD8fJsSaWFZcmXuIUYKDWUmEN2TZhTAh3pTEyqrUovz4otKc1OJDjNIcLErivEsd1ocJ CaQnlqRmp6YWpBbBZJk4OKUaGM0lLl+6bDr9EGfrdrUHi/Y37BNgONumJH3yYVOsA+Phkl7D R0ycGjxfbC7aPF4fWLL+HkN91VTx56FXA2xLHc+0snn4L+8+plDv+7/rpX9kvUa8tKHkVLtI vUmRqlkWdXMtrZ3TytuCqs49W6UmJeLyTphL2LRe9In/DKn8bU8THtyMbnBUYinOSDTUYi4q TgQAgxula6YCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/ZGzoEGfaBOrQsTNv8zFG3e-D8TI>
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, 26 Feb 2016 20:08:46 -0000

Dear Les et. al,

Please post any further comments you might have on this document.

--
Uma C.

From: Isis-wg [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; 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 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, January 12, 2016 5:25 PM
To: Christian Hopps; isis-wg@ietf.org<mailto: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 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Christian Hopps
Sent: Monday, November 30, 2015 11:45 PM
To: isis-wg@ietf.org<mailto: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:

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.

v2.23.0 | Report a Bug | By Email