Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Christian Hopps <chopps@chopps.org> Thu, 12 March 2020 11:33 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ACF3A0E0C; Thu, 12 Mar 2020 04:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HCBtr92_-VVM; Thu, 12 Mar 2020 04:33:58 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 044413A0E4C; Thu, 12 Mar 2020 04:33:57 -0700 (PDT)
Received: from stubbs.int.chopps.org.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1126860B4D; Thu, 12 Mar 2020 11:33:56 +0000 (UTC)
References: <CAHzoHbtmJGB8QY==A5EMzzSwh+8bQjhbVgPBjA3kHJGxpCD_zA@mail.gmail.com> <c8828557-85a4-d002-cc8f-a8cd8da0aeaa@cisco.com> <CAHzoHbsU-+fUDdr5knmUE87DudCswwF2qGi11SVSSypT2UXKaQ@mail.gmail.com> <MW3PR11MB45703130D6A8527ED0C4C9CDC1E80@MW3PR11MB4570.namprd11.prod.outlook.com> <12659_1582880639_5E58D77F_12659_66_1_53C29892C857584299CBF5D05346208A48DCA80D@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB4570EDAE9E6AF17C9CCC9899C1E80@MW3PR11MB4570.namprd11.prod.outlook.com> <7453_1582899837_5E59227C_7453_80_1_53C29892C857584299CBF5D05346208A48DD14BA@OPEXCAUBM43.corporate.adroot.infra.ftgroup><CAHzoHbu4k15xJ2mnwp=9Xa400gQBtBY=OaSh6sh3_8E_t30sdA@mail.gmail.com> <MW3PR11MB4570E85308182AEA3D9E1BDBC1E50@MW3PR11MB4570.namprd11.prod.outlook.com><CAHzoHbu3tNPv+=Fs-4o-PKxXhjt6tBReiyuyGVvFpdaVuJvqSA@mail.gmail.com> <MW3PR11MB457046873C2D009073459CCBC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com>
User-agent: mu4e 1.3.5; emacs 26.3
From: Christian Hopps <chopps@chopps.org>
To: spring@ietf.org
Cc: Chris Bowers <chrisbowers.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
In-reply-to: <MW3PR11MB457046873C2D009073459CCBC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com>
Date: Thu, 12 Mar 2020 07:33:56 -0400
Message-ID: <sa6r1xxn6xn.fsf@stubbs.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/fOZUJHWk_sTpxb3wtHa4XJLbPvw>
Subject: Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 11:34:07 -0000

Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org> writes:

> [KT] The behaviors currently listed in the draft do not have an argument nor is the use of B and N required for them. We cannot preclude a future use-case or extension where such behaviors introduced are also applicable to ISIS. So IMHO ruling such aspects out might not be the right thing to do from a protocol extensibility perspective.

No opinion here on this sub-sub-TLV; however, it has been stated elsewhere that this document will be re-spun for each new behavior that is to be carried in IS-IS (not my personal preference, fwiw...).

Thanks,
Chris.
[as WG member]