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

Chris Bowers <chrisbowers.ietf@gmail.com> Thu, 12 March 2020 15:01 UTC

Return-Path: <chrisbowers.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32973A0A47; Thu, 12 Mar 2020 08:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 r7E0xA5yvSUf; Thu, 12 Mar 2020 08:01:37 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC9D3A0A23; Thu, 12 Mar 2020 08:01:36 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id h16so4552333qtr.11; Thu, 12 Mar 2020 08:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLi7H3RPnETsXYLmuNvBbKUEubYFTdqZklsjZ6BwgGA=; b=i4NMkRGDXH0A+6fB5cxnTVMWDFFo+O3Sj8sIhrtm0OEB9y5Eotal0V62MtRi2mG54/ aHSXhrBssDM/aGzz7uqV+RrC59UkGGGX1lZRDYnQJS0MUljbfAK9B7688+LOP+1NG5x5 EmC9FaGTfKLGjgf6mALeyWahp+tPTsnd14o6Xizy0OWWRHG+ACnfAnzIulcB2Hh+olQI Jjx7S6oYVxs3vOmz/bV0OJSBU4hdqGf220eW6P7nl2H1grm4DtwQsx6N7aQqqsnkuZ/M bYA6HNc5964IeNkxbaU0QFiqfJUsfR2B4qDnuBb/ll1r0Put5squsdpcTxwthMwps4b0 I+Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SLi7H3RPnETsXYLmuNvBbKUEubYFTdqZklsjZ6BwgGA=; b=LTkOOWWfm1ELpAwolM4yrq622H8BDr6zHxnopVGUnA4Uiw+bOAR0e5G11agMwMRqIC fle6B7c04Jy5K7S86GstndkB4GJfblF2zweQdUuVb8t/L+R0mJj//a9IvnBJrnbTwq8H AQa0Ypjw7XUW1Jc5j+wumEn1N8+EnIGLCQxVRHtiqLHvanUUq0Q6WMQgtq4Ziim3YAwt rMKh2ySJByt+9rQ0zDkm0qV/Ej98mztzEyuJS9+CUSBAcibJ9MmyQwoT7u+Vvn4O8ez1 0WbU7khhCDou6nNyRhUoUEBc2/6sKIDTL28Xz393ts5qBGJ2X91n466kQt46DwzYjhIx DrIw==
X-Gm-Message-State: ANhLgQ0Dxaaf94tvYuz2UzCo5rBJkVPW8fOl0CS4m0nc6D92YJkAGBO1 ZKYrHJIwtPfgEMOr08GGw0Zd85BDXo06t8CBu1zSQD/D
X-Google-Smtp-Source: ADFU+vuQX7K3Qtw5JpRDmcAj+vTXHXwaum7cmXO5e2Y+20fu6Z8EAhaC3KjVW7WXBGPoNNeHgpB86KvxnlI+zZisVHY=
X-Received: by 2002:ac8:18f3:: with SMTP id o48mr7963892qtk.368.1584025295708; Thu, 12 Mar 2020 08:01:35 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <MW3PR11MB457046873C2D009073459CCBC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Thu, 12 Mar 2020 09:58:38 -0500
Message-ID: <CAHzoHbumzM76CFZCp+ec_OHvo+NCbMRRhtx7evGuw=DrZk1rZA@mail.gmail.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, SPRING WG List <spring@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>
Content-Type: multipart/alternative; boundary="00000000000010e5fd05a0a9a188"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/xtRJSOITJvjUIaq_IuvYfSktgN8>
Subject: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 15:01:40 -0000

Peter,

I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from
draft-ietf-lsr-isis-srv6-extensions.  I think that we should leave the
ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID
Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those sub-TLVs.

I don't think that the current text describing the SRv6 SID Structure
Sub-Sub-TLV would result in interoperable implementations.  Based on the
discussion with Ketan below, it appears that use cases for ISIS speakers
receiving advertised values of LB Length, LN Length, Fun. Length, and Arg.
Length are not currently well-defined.    So I think it makes sense to
defer the definition of the SRv6 SID Structure Sub-Sub-TLV to a future
document.

Thanks,
Chris

On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Chris,
>
>
>
> Dropping the draft-ietf-spring-srv6-network-programming authors since we
> are now back to discussing the ISIS extensions.
>
>
>
> Please check inline below.
>
>
>
> *From:* Chris Bowers <chrisbowers.ietf@gmail.com>
> *Sent:* 05 March 2020 21:53
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com>; lsr@ietf.org; SPRING
> WG List <spring@ietf.org>; draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programming@ietf.org>; Peter Psenak
> (ppsenak) <ppsenak@cisco.com>; Bruno Decraene <bruno.decraene@orange.com>
> *Subject:* Re: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Ketan,
>
>
>
> See inline [CB].
>
>
>
> On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) <
> ketant@cisco.com> wrote:
>
> Hi Chris,
>
>
>
> You are right in that there is no assumption that all SRv6 locators in a
> domain are allocated from the same block. Therefore knowing the blocks used
> in the domain is useful.
>
>
>
> [CB] Since you refer to "blocks" (plural) in this sentence, are you saying
> that in the scenario where all SRv6 locators in a domain are not allocated
> from the same block, you would expect different routers in the same domain
> to advertise different values of B and N?
>
> *[KT] While personally I believe it would not be the usual case, it is
> left to the operator.*
>
>
>
> For example, assume we have a network where all SRv6 locators in a domain
> are not allocated from the same block.  Router A advertises an SRv6 Locator
> TLV with locator = 2000::/64, and an SRv6 End SID sub-TLV with some
> endpoint behavior.  Router B advertises an SRv6 Locator TLV with locator =
> 3000::/64, and an SRv6 End SID sub-TLV with some endpoint behavior. What
> should routers A and B advertise as the values of B and N in their SRv6 SID
> Structure Sub-Sub-TLVs ?
>
> *[KT] It is difficult for me to figure out what the block and node parts
> are with such an addressing.*
>
>
>
>
>
> The IGP drafts covers the advertisement of the B and N parts of the
> locally configured locator on the node via IGPs. On the receiver side, the
> IGP may not really do much with this information, however it enables
> propagation of this information from all nodes in the network to be
> advertised out via BGP-LS (or other mechanisms) as part of the topology
> feed. Once this is part of the topology feed, it enables use-cases on
> controllers to perform network wide validation of the SRv6 SID block
> provisioning and can also help in automation of the security aspects
> described in
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
>
>
>
> [CB] If an ISIS speaker is not expected to do anything with B and N, then
> I think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify
> this.  I have a similar observation about Fun. Length and Arg. Length in
> the SRv6 SID Structure Sub-Sub-TLV .  As far as I can tell, none of the
> endpoint behaviors that are currently specified to be carried in ISIS End,
> End.X, and LAN End.X SIDs sub-TLVs uses an Argument, so there is never a
> case where an SRv6 SID Structure Sub-Sub-TLV should have a non-zero value
> for Arg. Length. What should an ISIS speaker do if it receives a non-zero
> value of the Arg. Length for an endpoint behavior that doesn't use an
> argument?  Are there any use cases envisioned where an ISIS speaker needs
> to know the Arg. Length ?
>
> *[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.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Chris Bowers <chrisbowers.ietf@gmail.com>
> *Sent:* 02 March 2020 23:39
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org
> <40cisco..com@dmarc.ietf.org>>; lsr@ietf.org; SPRING WG List <
> spring@ietf.org>; draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programming@ietf.org>; Peter Psenak
> (ppsenak) <ppsenak@cisco.com>; Bruno Decraene <bruno.decraene@orange.com>
> *Subject:* Re: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Ketan,
>
>
>
> Based on current documents, allocating all SRv6 locators used in a domain
> from a single block is optional.
>
>
>
> However, assuming for the moment that a network operator has chosen to
> allocate all SRv6 locators used in a domain from a single block, so that
> there is a well-defined value of B and N across a domain, what is the use
> of having a router advertise its own understanding of these two values?
> And what is a receiver supposed to do with this information?
>
>
>
> Thanks,
>
> Chris
>
>
>
> On Fri, Feb 28, 2020 at 8:23 AM <bruno.decraene@orange.com> wrote:
>
> Hi Ketan,
>
>
>
> Thanks fort the follow up.
>
> Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* lsr@ietf.org; SPRING WG List;
> draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak)
> *Subject:* RE: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Hi Bruno,
>
>
>
> I believe the description and usage of Locator is very well described and
> covered in the net-pgm draft as also the corresponding IGP extensions. Is
> the question is more about the “block” part of it (what is not in the block
> part is in the node part as per the text in the net-pgm draft)?
>
>
>
> The “block” is again not a new thing. Please check the following:
>
> Under
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
> … look for “block”
>
> https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6
>
>
>
> [Bruno]
>
> To clarify, my question was not specific to “block” but related to the
> usage, by the receiver, of the following piece of information:
>
>
>
>       LB Length: SRv6 SID Locator Block length
>
>       LN Length: SRv6 SID Locator Node length
>
>       Fun. Length: SRv6 SID Function length
>
>       Arg. Length: SRv6 SID Arguments length
>
>
>
>
>
> So perhaps I don’t get Chris’s point and would wait for him to clarify.
>
> [Bruno] I’ll leave this to Chris.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *
> bruno.decraene@orange.com
> *Sent:* 28 February 2020 14:34
> *To:* Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org
> <40cisco..com@dmarc.ietf.org>>; Chris Bowers <chrisbowers.ietf@gmail.com>
> *Cc:* lsr@ietf.org; SPRING WG List <spring@ietf.org>;
> draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programming@ietf.org>; Peter Psenak
> (ppsenak) <ppsenak@cisco.com>
> *Subject:* Re: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Hi Ketan,
>
>
>
>
>
>
>
> *From:* Lsr [mailto:lsr-bounces@ietf.org <lsr-bounces@ietf.org>] *On
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* Friday, February 28, 2020 6:30 AM
>
>
>
> Hi Chris,
>
>
>
> I agree with Peter and I would suggest to drop LSR since this is not a
> protocol specific thing.
>
>
>
> I believe the text in draft-ietf-spring-srv6-network-programming clears
> says what locator block and locator node are. What more details do you
> think are required?
>
>
>
> [Bruno] Speaking as an individual, the draft could possibly clarify the
> usage of these information/fields by the receiver. Possibly using the same
> name/term (e.g. SRv6 SID Locator Block length) to ease the references
> between both drafts.
>
>
>
> Thanks,
>
> --Bruno
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *Chris Bowers
> *Sent:* 27 February 2020 22:46
> *To:* lsr@ietf.org; SPRING WG List <spring@ietf.org>
> *Cc:* Peter Psenak (ppsenak) <ppsenak@cisco.com>
> *Subject:* [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> SPRING and LSR WGs,
>
>
>
> I think that we need a much more detailed description of the locator block
> and locator node in either draft-ietf-spring-srv6-network-programming or
> draft-ietf-lsr-isis-srv6-extensions.  See original email below.
>
>
>
> Thanks,
>
> Chris
>
>
>
> On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak <ppsenak@cisco.com> wrote:
>
> Hi Chris,
>
> On 27/02/2020 17:54, Chris Bowers wrote:
> > LSR WG,
> >
> > Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> > SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> > locator block length and the locator node length.  The text refers to
> > [I-D.ietf-spring-srv6-network-programming] for the definition of these
> > concepts.
> >
> > As far as I can tell, the only reference to locator block and locator
> > node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> > which has the following text:
> >
> >     A locator may be represented as B:N where B is the SRv6 SID block
> >     (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> >     identifier of the parent node instantiating the SID...
> >
> > I think that we need a much more detailed description of the locator
> > block and locator node.
>
> sure, but that would be in the
> draft-ietf-spring-srv6-network-programming-10, not in
> draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
> specific constructs.
>
> thanks,
> Peter
>
> >
> > Thanks,
> >
> > Chris
> >
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>