Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
Weiqiang Cheng <chengweiqiang@chinamobile.com> Mon, 13 April 2020 07:00 UTC
Return-Path: <chengweiqiang@chinamobile.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 0E6A63A1079; Mon, 13 Apr 2020 00:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.212
X-Spam-Level: ***
X-Spam-Status: No, score=3.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 afICppJoZzam; Mon, 13 Apr 2020 00:00:30 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33C463A1054; Sun, 12 Apr 2020 23:54:07 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65e940ba37f6-31832; Mon, 13 Apr 2020 14:50:12 +0800 (CST)
X-RM-TRANSID: 2ee65e940ba37f6-31832
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc (unknown[10.2.53.197]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee25e940b9fb28-0c0d3; Mon, 13 Apr 2020 14:50:09 +0800 (CST)
X-RM-TRANSID: 2ee25e940b9fb28-0c0d3
From: Weiqiang Cheng <chengweiqiang@chinamobile.com>
To: "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com>, 'Peter Psenak' <ppsenak=40cisco.com@dmarc.ietf.org>, 'Chris Bowers' <chrisbowers.ietf@gmail.com>
Cc: lsr@ietf.org, 'SPRING WG List' <spring@ietf.org>, "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, 'Bruno Decraene' <bruno.decraene@orange.com>
References: <CAHzoHbtmJGB8QY==A5EMzzSwh+8bQjhbVgPBjA3kHJGxpCD_zA@mail.gmail.com> <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> <CAHzoHbumzM76CFZCp+ec_OHvo+NCbMRRhtx7evGuw=DrZk1rZA@mail.gmail.com> <4bf64ede-c20b-2269-af11-1dffc5328935@cisco.com> <CAHzoHbv3k2Thri-hx=FYOYFXEgqDXQagLzJjC8XQ2btgYgey0Q@mail.gmail.com> <84b355a9-d3ce-af0e-ae60-f765aab4ec63@cisco.com> <CAHzoHbsdkd7p2RdyZ2Y3_e1XTLTn=zt+GKbmGYmaAYjsNC=hNg@mail.gmail.com> <b5d0a98a-28e4-13c1-961f-fa93eb5c09af@cisco.com> <0eaa0f3d69d840b1be86c5717d70c67e@huawei.com>
In-Reply-To: <0eaa0f3d69d840b1be86c5717d70c67e@huawei.com>
Date: Mon, 13 Apr 2020 14:50:08 +0800
Message-ID: <069701d6115f$c607bed0$52173c70$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0698_01D611A2.D42AFED0"
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: zh-cn
Thread-Index: AQHWCGB+MqSFXsy1FU2jpPoSxjFNiKhrbwyAgAGDKdCACbs5AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Pwy05xAtRr6t3wVBsO28ArUk-o0>
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: Mon, 13 Apr 2020 07:00:37 -0000
Hi Xuesong, I agree with Xuesong. It has been in the draft for quite some time and is useful. I do not see any issues with the proposed encodings for the SID Structure sub-TLV in the draft. B.R. Weiqiang Cheng 发件人: spring [mailto:spring-bounces@ietf.org] 代表 Gengxuesong (Geng Xuesong) 发送时间: 2020年4月7日 10:56 收件人: Peter Psenak; Chris Bowers 抄送: lsr@ietf.org; SPRING WG List; Ketan Talaulikar (ketant); Bruno Decraene 主题: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions Hi Chris, Peter, Here are some personal opinions about this discussion: - Keep LBL and LNL in the structure sub-TLV is better for protocol scalability and flexibility, an operator could choose to allocate SRv6 locator from the same locator block, or from different locator block. - It is suggested to design SID structure sub-TLV as a general TLV which could be used for BGP/BGP-LS/ISIS/OSPF. - SID is supposed to be advertised with suitable protocol based on the use case. Whether it contains argument or not is not relevant. B.R. Xuesong -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Peter Psenak Sent: Monday, April 6, 2020 7:03 PM To: Chris Bowers <chrisbowers.ietf@gmail.com> Cc: lsr@ietf.org; SPRING WG List <spring@ietf.org>; Ketan Talaulikar (ketant) <ketant@cisco.com>; Bruno Decraene <bruno.decraene@orange.com> 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 Chris, On 01/04/2020 21:58, Chris Bowers wrote: > Peter, > > There seem to be two disconnects in this discussion. > > 1) The response below implies that the encodings in > draft-ietf-lsr-isis-srv6-extensions are supposed represent the case > where the locators are allocated from several different IPv6 address > blocks (for example, blocks S1/s1 through Sn/sn). However, > draft-ietf-spring-srv6-network-programming and > draft-ietf-6man-segment-routing-header only discuss the case where the > locators are allocated from a single block (S/s). If an > implementation is expected to properly encode the case where locators > are allocated from several different IPv6 address blocks, then I think > that case should be explicitly described in these documents. There is no statement in draft-ietf-spring-srv6-network-programming that the block is unique. As an example, Iliad authorized me to indicate that their SRv6 deployment involves several blocks. > > 2) The response below says "To be able to find out where the func > and arg are located, you need to know the LOC length, e.g. Block and > Node length." However, the SRv6 SID Structure Sub-Sub-TLV is carried > within the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID > Sub-TLVs, which are carried within the SRv6 Locator TLV. not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in SRv6 Locator TLV. thanks, Peter > The SRv6 Locator TLV > has a Loc-Size field. Why would the value of the LOC length computed > as the sum of the Block and Node length ever be different from the > value in the Loc-Size field? > > Chris > > > On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak <ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com>> wrote: > > Chris, > > please see inline: > > > On 23/03/2020 17:39, Chris Bowers wrote: > > Peter, > > > > The proposed SRv6 SID Structure Sub-Sub-TLV has several problems. > > > > 1) As discussed in item#3 below, it is not clear that flooding LB > > Length, LN Length, Fun. Length, and Arg. Length to all ISIS > speakers is > > really the right approach. However, if the WG determines that it > is the > > right approach, the current encodings of this information in the > > proposed SRv6 SID Structure Sub-Sub-TLV are problematic. As > discussed > > earlier in this thread, a network operator may choose to not > allocate > > all locators from a single block, so LB Length and LN Length may > not be > > well-defined. > > I'm not sure what do you mean by not "well defined". For every SID you > need to know the LOC (B+N) part. If you guarantee that it is the > same on > all nodes, you know it from the local config, otherwise, you advertise > it with a SID. > > > The current encoding of the SRv6 SID Structure > > Sub-Sub-TLV makes it difficult to represent this situation. The > simple > > thing to do for nodes that don't have a well-defined value of LB > Length > > and LN Length would be to not advertise a value for LB Length and LN > > Length. However, since the currently proposed SRv6 SID Structure > > Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg. > Length > > into a single sub-sub-TLV, if a node wants to advertise values > for Fun. > > Length and Arg. Length, it also has to advertise values for LB > Length > > and LN Length. It seems like a better approach would be to have > > different sub-sub-TLVs, one for LB Length and LN Length, and a > separate > > one for Fun. Length and Arg. Length to be able to better > represent this > > situation. > > > I'm afraid you are missing an important point. > > SRv6 SID is defined as LOC:FUNCT:ARG, where LOC is represented as B:N. > To be able to find out where the func and arg are located, you need to > know the LOC length, e.g. Block and Node length. Advertising just Func > and Arg length does not help. > > > > > > 2) Now consider the situation where a network operator chooses to > > allocate all locators from a single block, so that LB Length and LN > > Length are well-defined across the network. A given node should > > presumably advertise its own understanding of LB Length and LN > Length. > > A given node's understanding of LB Length and LN Length is a > property of > > the node. It is not a property of a given End SID. The currently > > proposed SRv6 SID Structure Sub-Sub-TLV however is carried within > each > > End SID Sub-TLV. With the currently proposed encoding, > presumably an > > implementation is expected to send the exact same values of LB > Length > > and LN Length for all of the End SIDs that it advertises. Not > only is > > this inefficient, but it creates the need for logic to decide > what to do > > when different End SIDs advertised by the same node carry different > > values of LB Length and LN Length in their sub-sub-TLVs. It > seems like > > a better approach would be for a given node to advertise its > > understanding of the value of LB Length and LN Length in a > sub-TLV of > > the Router Capability TLV. > > When we design the encoding, we have to define it such, that it > supports > all possible use cases. We can not design the encoding that works for > single use case (allocate all locators from a single block) and does > not > work for others - different block from different node, multiple blocks > on a single node (e.g. border node), which are all valid. > > > > > 3) At this point, the only use case that has been proposed for > flooding > > the LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS > > speakers is to make it more convenient for BGP-LS to get those > values to > > an external controller as part of a topology feed from any ISIS > node. > > No use case has been proposed for ISIS speakers themselves to > make use > > of the information. It seems like a more scalable approach would > be to > > use BGP-LS sessions to collect the information from the subset of > nodes > > that actually produce the relevant information. So far there are > no End > > SIDs defined that are advertised in ISIS that have a non-zero Arg. > > Length. If an End SID with non-zero Arg. Length were to be > proposed in > > the future as needing to be flooded to all ISIS nodes, it seems > likely > > that the new End SID would also be advertised using the BGP > IP/VPN/EVPN > > control plane. So it seems like a viable alternative for this > > hypothetical future End SID would be to have the subset of nodes > that > > have non-zero Arg. Length values communicate to an external > controller > > via BGP sessions. I think the WG needs a more detailed > discussion of a > > concrete use case in order to determine whether flooding LB > Length, LN > > Length, Fun. Length, and Arg. Length to all ISIS speakers is > really the > > right approach. > > there are networks, where BGP is not deployed on all nodes, only on a > few nodes that re-distribute the information to BGP-LS. In such case we > need the IGP to distribute this data. > > Argument that "it seems likely that the new End SID would also be > advertised using the BGP IP/VPN/EVPN" is a wishful thinking that we can > not based our encoding on. > > > > > > Given the lack of a compelling use case for flooding LB Length, LN > > Length, Fun. Length, and Arg. Length to all ISIS speakers and the > > problems with the currently proposed encodings for doing that, I > think > > that the SRv6 SID Structure Sub-Sub-TLV should be removed from > > draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB > Length, > > LN Length, Fun. Length, and Arg. Length to all ISIS speakers can be > > defined in a future document. > > The security use case has already been pointed out earlier in this > thread: > > > <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26# > section-5 > > Given the arguments I mentioned above, I respectfully disagree with the > removal of the SID Structure Sub-Sub-TLV from the ISIS SRv6 draft. > > thanks, > Peter > > > > > > Thanks, > > Chris > > > > On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak <ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote: > > > > Hi Chris, > > > > On 12/03/2020 15:58, Chris Bowers wrote: > > > 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 > > > > SRv6 base spec defines SID B, L, A, F. > > > > SRv6 protocol specs are advertising these values with the > SRv6 SID, > > they > > don't use them. The usage is outside of the scope of the protocol > > drafts. What exactly is the problem? > > > > thanks, > > Peter > > > > > > > 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) > > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto: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 > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>> > > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>>>> > > > *Sent:* 05 March 2020 21:53 > > > *To:* Ketan Talaulikar (ketant) <ketant@cisco.com > < <mailto:ketant@cisco.com> mailto:ketant@cisco.com> > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>> > > > *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com > < <mailto:ketant@cisco.com> mailto:ketant@cisco.com> > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>>; > > <mailto:lsr@ietf.org> lsr@ietf.org < <mailto:lsr@ietf.org> mailto:lsr@ietf.org> <mailto:lsr@ietf.org > < <mailto:lsr@ietf.org> mailto:lsr@ietf.org>> < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org> > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; > > > SPRING WG List <spring@ietf.org > < <mailto:spring@ietf.org> mailto:spring@ietf.org> <mailto:spring@ietf.org > < <mailto:spring@ietf.org> mailto:spring@ietf.org>> > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>>>>; > > > draft-ietf-spring-srv6-network-programming > > > <draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>> > > > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>; Peter > > > Psenak (ppsenak) <ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>>>; > > > Bruno Decraene <bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com>> > > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto: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) > > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto: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____> 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 > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>> > > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>>>> > > > *Sent:* 02 March 2020 23:39 > > > *To:* Ketan Talaulikar (ketant) <ketant@cisco.com > < <mailto:ketant@cisco.com> mailto:ketant@cisco.com> > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>> > > > *Cc:* Ketan Talaulikar (ketant) > > > <ketant=40cisco.com@dmarc.ietf.org > < <mailto:40cisco.com@dmarc.ietf.org> mailto:40cisco.com@dmarc.ietf.org> > > <mailto:40cisco.com@dmarc.ietf.org > < <mailto:40cisco.com@dmarc.ietf.org> mailto:40cisco.com@dmarc.ietf.org>> > > > <mailto:40cisco..com@dmarc.ietf.org > < <mailto:40cisco..com@dmarc.ietf.org> mailto:40cisco..com@dmarc.ietf.org> > > <mailto:40cisco..com@dmarc.ietf.org > < <mailto:40cisco..com@dmarc.ietf.org> mailto:40cisco..com@dmarc.ietf.org>>>>; <mailto:lsr@ietf.org> lsr@ietf.org > < <mailto:lsr@ietf.org> mailto:lsr@ietf.org> > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>> > > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG > > List < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>> > > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>>>>; > > > draft-ietf-spring-srv6-network-programming > > > > <draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>> > > > > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>; > > > Peter Psenak (ppsenak) <ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > > > <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com>>>>; > > Bruno Decraene > > > <bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com>> > < <mailto:bruno.decraene@orange.com%20%3cmailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto: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 > > < <mailto:bruno.decraene@orange.com%20%3cmailto:bruno.decraene@orange.com> bruno.decraene@orange.com <mailto:bruno.decraene@orange.com> > < <mailto:bruno.decraene@orange.com%20%3cmailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>> > > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com>>>> wrote:____ > > > > > > Hi Ketan,____ > > > > > > ____ > > > > > > Thanks fort the follow up.____ > > > > > > Clarification inline [Bruno]____ > > > > > > ____ > > > > > > *From**:*Ketan Talaulikar (ketant) > > [mailto:ketant@cisco.com <mailto:ketant@cisco.com> > < <mailto:ketant@cisco.com%20%3cmailto:ketant@cisco.com> mailto:ketant@cisco.com <mailto:ketant@cisco.com>> > > > <mailto:ketant@cisco.com > < <mailto:ketant@cisco.com> mailto:ketant@cisco.com> <mailto:ketant@cisco.com > < <mailto:ketant@cisco.com> mailto:ketant@cisco.com>>>] > > > *Sent:* Friday, February 28, 2020 11:11 AM > > > *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar > (ketant); > > > Chris Bowers > > > *Cc:* <mailto:lsr@ietf.org> lsr@ietf.org < <mailto:lsr@ietf.org> mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>> > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto: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> 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> 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 > < <mailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org> > > < <mailto:lsr-bounces@ietf.org%20%3cmailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> > > > <mailto:lsr-bounces@ietf.org > < <mailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org> > > < <mailto:lsr-bounces@ietf.org%20%3cmailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>>> > *On Behalf Of > > > <mailto:*bruno.decraene@orange.com> *bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com>> > < <mailto:bruno.decraene@orange.com%20%3cmailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com> > > <mailto:bruno.decraene@orange.com > < <mailto:bruno.decraene@orange.com> mailto:bruno.decraene@orange.com>>> > > > *Sent:* 28 February 2020 14:34 > > > *To:* Ketan Talaulikar (ketant) > > > <ketant=40cisco.com@dmarc.ietf.org > < <mailto:40cisco.com@dmarc.ietf.org> mailto:40cisco.com@dmarc.ietf.org> > > <mailto:40cisco.com@dmarc.ietf.org > < <mailto:40cisco.com@dmarc.ietf.org> mailto:40cisco.com@dmarc.ietf.org>> > > > <mailto:40cisco..com@dmarc.ietf.org > < <mailto:40cisco..com@dmarc.ietf.org> mailto:40cisco..com@dmarc.ietf.org> > > <mailto:40cisco..com@dmarc.ietf.org > < <mailto:40cisco..com@dmarc.ietf.org> mailto:40cisco..com@dmarc.ietf.org>>>>; Chris Bowers > > > <chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>> > > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com> > <mailto:chrisbowers.ietf@gmail.com > < <mailto:chrisbowers.ietf@gmail.com> mailto:chrisbowers.ietf@gmail.com>>>> > > > *Cc:* <mailto:lsr@ietf.org> lsr@ietf.org < <mailto:lsr@ietf.org> mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>> > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG List > > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>> > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>>>>; > > > draft-ietf-spring-srv6-network-programming > > > > <draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>> > > > > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org> > > <mailto:draft-ietf-spring-srv6-network-programming@ietf.org > < <mailto:draft-ietf-spring-srv6-network-programming@ietf.org> mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>; > > > Peter Psenak (ppsenak) <ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > > > <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto: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 > < <mailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org> > > < <mailto:lsr-bounces@ietf.org%20%3cmailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org <mailto: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 > < <mailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org> > > < <mailto:lsr-bounces@ietf.org%20%3cmailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> > > > <mailto:lsr-bounces@ietf.org > < <mailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org> > > < <mailto:lsr-bounces@ietf.org%20%3cmailto:lsr-bounces@ietf.org> mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>>> > *On Behalf Of *Chris Bowers > > > *Sent:* 27 February 2020 22:46 > > > *To:* <mailto:lsr@ietf.org> lsr@ietf.org < <mailto:lsr@ietf.org> mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>> > > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org> > < <mailto:lsr@ietf.org%20%3cmailto:lsr@ietf.org> mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG List > > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>> > > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org> > < <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org> mailto:spring@ietf.org <mailto:spring@ietf.org>>>> > > > *Cc:* Peter Psenak (ppsenak) > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> ppsenak@cisco.com <mailto:ppsenak@cisco.com> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > > > <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com > < <mailto:ppsenak@cisco.com> mailto: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 > > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> ppsenak@cisco.com <mailto:ppsenak@cisco.com> > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com> > < <mailto:ppsenak@cisco.com%20%3cmailto:ppsenak@cisco.com> mailto:ppsenak@cisco.com <mailto: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.____ > > > > > > _______________________________________________ spring mailing list <mailto:spring@ietf.org> spring@ietf.org <https://www.ietf.org/mailman/listinfo/spring> https://www.ietf.org/mailman/listinfo/spring
- [spring] clarification of locator block and locat… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… bruno.decraene
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… bruno.decraene
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Christian Hopps
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Gengxuesong (Geng Xuesong)
- Re: [spring] [Lsr] clarification of locator block… Derek Yeung
- Re: [spring] [Lsr] clarification of locator block… Weiqiang Cheng
- Re: [spring] [Lsr] clarification of locator block… Acee Lindem (acee)