Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05
I support publication of this document, as a co-author. Chris On Mon, Nov 22, 2021 at 1:47 PM Acee Lindem (acee) wrote: > This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. > Please post your support or objection to this list by 12:00 AM UTC on Dec 14th > , 2021. Also please post your comments on the draft. I’m allowing as extra > week as I like to get some additional reviews – although my comments have > been addressed. > > > > Thanks, > Acee > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00
LSR, I am not aware of any undisclosed IPR related to this draft. Chris On Mon, Nov 22, 2021 at 8:13 AM Acee Lindem (acee) wrote: > Draft Authors and Contributors, > > > > Are you aware of any IPR that applies to > draft-decraeneginsberg-lsr-isis-fast-flooding-00? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, > > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05 (WG Last Call Iteration)
LSR, I am not aware of any undisclosed IPR related to this draft. Chris On Mon, Nov 22, 2021 at 1:52 PM Acee Lindem (acee) wrote: > Authors, Contributors, > > > > Are you aware of any IPR that applies to > draft-ietf-lsr-isis-flood-reflection-05? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, > > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt
I support WG adoption of draft-chen-isis-ttz as experimental. Chris On Tue, Aug 18, 2020 at 9:17 AM Acee Lindem (acee) wrote: > > > Based on the discussions in the last meeting and on the mailing list > regarding draft-chen-isis-ttz-11, the chairs feel that there are enough > differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to > consider advancing it independently on the experimental track. > > > > These differences include abstraction at arbitrary boundaries and IS-IS > extensions for smooth transition to/from zone abstraction. > > > > We are now starting an LSR WG adoption call for > draft-chen-isis-ttz-11.txt. Please indicate your support or objection to > adoption prior to Tuesday, September 2nd, 2020. > > > > Thanks, > > Acee and Chris > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01
I support WG adoption of draft-przygienda-lsr-flood-reflection. The only IPR that I am aware of that may be related to this draft has already been disclosed. Chris On Wed, Jun 10, 2020 at 2:29 PM Christian Hopps wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection > > The draft would be adopted on the Experimental track. > > Please indicate your support or objection by June 24, 2020. > > Authors, please respond to the list indicating whether you are aware of > any IPR that applies to this draft. > > Thanks, > Chris and Acee. > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
I support WG adoption of draft-przygienda-lsr-flood-reflection. Chris On Thu, Jun 4, 2020 at 1:05 PM Tony Przygienda wrote: > I would like to officially call out for adoption of > https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as > WG document > > At this point in time flood reflection has been implemented and works > meeting use case requirements of multiple customers which neither TTZ nor > draft-proxy is addressing or can satisfy in terms of deployment realities. > While we would love to not squat on codepoints and ideally have an > interoperable solution between vendors it will be the customer reality that > will drive deployment and ultimately what runs in their networks. > > thanks > > --- tony > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
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. 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. 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 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 a
Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
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. 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. 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. 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. 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. Thanks, Chris On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak 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
Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
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) 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 > *Sent:* 05 March 2020 21:53 > *To:* Ketan Talaulikar (ketant) > *Cc:* Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING > WG List ; draft-ietf-spring-srv6-network-programming < > draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak > (ppsenak) ; Bruno Decraene > *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) < > ket...@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* > > > &g
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) 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? 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 ? > > > 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 ? Thanks, > > Ketan > > > > *From:* Chris Bowers > *Sent:* 02 March 2020 23:39 > *To:* Ketan Talaulikar (ketant) > *Cc:* Ketan Talaulikar (ketant) ; > lsr@ietf.org; SPRING WG List ; > draft-ietf-spring-srv6-network-programming < > draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak > (ppsenak) ; Bruno Decraene > *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 wrote: > > Hi Ketan, > > > > Thanks fort the follow up. > > Clarification inline [Bruno] > > > > *From**:* Ketan Talaulikar (ketant) [mailto:ket...@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 > &
[Lsr] Implementation section of draft-ietf-lsr-isis-srv6-extensions
LSR, I would like to update the implementation section of draft-ietf-lsr-isis-srv6-extensions to read: 11.3. Juniper Juniper's ISIS SRv6 implementation supports the following functionalities: Types of SID supported: End, End.X, LAN End.X Intra/Inter area/level support: Yes Anycast SID support: Yes, no A-flag support (Section 6) SID Structure Sub-Sub-TLV: No Thanks, Chris ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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 wrote: > Hi Ketan, > > > > Thanks fort the follow up. > > Clarification inline [Bruno] > > > > *From**:* Ketan Talaulikar (ketant) [mailto:ket...@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 *On Behalf Of * > bruno.decra...@orange.com > *Sent:* 28 February 2020 14:34 > *To:* Ketan Talaulikar (ketant) ; > Chris Bowers > *Cc:* lsr@ietf.org; SPRING WG List ; > draft-ietf-spring-srv6-network-programming < > draft-ietf-spring-srv6-network-programm...@ietf.org>; 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 Ketan, > > > > > > > > *From:* Lsr [mailto:lsr-boun...@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 *On Behalf Of *Chris Bowers > *Sent:* 27 February 2020 22:46 > *To:* lsr@ietf.org; SPRING WG List > *Cc:* Peter Psenak (ppsenak) > *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 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. > > >
[Lsr] clarification of locator block and locator node in draft-ietf-lsr-isis-srv6-extensions
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. Thanks, Chris ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] feedback on draft-ietf-lsr-isis-srv6-extensions-04 related to algorithms
All, The current text from Section 5 (below) doesn't specify if locators associated with algorithms with values 1-126 SHOULD or SHOULD NOT be advertised in Prefix Reachability TLVs. In particular, it seems like the text should specify the expected behavior for locators associated with algorithm 1 (Strict SPF). Locators associated with Flexible Algorithms [I-D.ietf-lsr-flex-algo] SHOULD NOT be advertised in Prefix Reachability TLVs (236 or 237). Locators associated with algorithm 0 (for all supported topologies) SHOULD be advertised in a Prefix Reachability TLV (236 or 237) so that legacy routers (i.e., routers which do NOT support SRv6) will install a forwarding entry for algorithm 0 SRv6 traffic. Thanks, Chris ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
All, I'm forwarding this question and subsequent response to the list because it looks like I accidentally sent it only to Peter before. Chris On Sat, Feb 8, 2020 at 3:25 AM Peter Psenak wrote: > Hi Chris, > > On 07/02/2020 23:15, Chris Bowers wrote: > > Peter, > > > > Thanks for the clarification. > > > > Can you also clarify how a receiver should interpret a locator > > advertisement that doesn't have a corresponding RFC7794 advertisement? > > > > Modifying the example below, suppose I receive a locator advertisement > > from router R7 with locator = ::/64 and End-SID ::1, but R7 > > doesn't originate an RFC7794 advertisement for ::/64. Can I > > conclude that ::/64 is not Anycast, so it can be used as a Node-SID > > when constructing TE paths as discussed below ? > > yes. That's the only reasonable choice. > > Implementation may also check if the same locator is not advertised by > some other node in addition. But I would not mandate that in the spec. > > thanks, > Peter > > > > Thanks, > > Chris > > > > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak > <mailto:ppse...@cisco.com>> wrote: > > > > Hi Chris, > > > > On 04/02/2020 23:17, Chris Bowers wrote: > > > Peter, > > > > > > Suppose I receive a locator advertisement from router R7 with > > > locator = ::/64 and End-SID ::1. I would like to be able > > to use > > > End-SID ::1 as > > > a Node-SID when constructing traffic engineered paths. That is, > > I want > > > to know that > > > the person or system that configured R7 believes that ::/64 > > > is NOT owned by more than one router within the same routing > domain. > > > > ##PP > > sure, if the A-bit is not set, you should be fine to pick the SID > > from a > > locator. Please see below why. > > > > > > > > Since we are going with Interpretation I) below, a prefix can be > > (a) a > > > Node Prefix, (b) an Anycast Prefix, > > > or (c) neither of them. > > > > ##PP > > above is correct in general. > > > > However, given that locator is non-/128, N-bit does not apply per > > RFC7794. So for a locator you only have (b) or (c) and you would only > > want to avoid (b) for what you want to do above. > > > > > > > If I receive an RFC7794 advertisement from R7 > > > for ::/64 with N=0, A=0, > > > I can only conclude that ::/64 is either (a) a Node Prefix or > > (c) > > > neither a Node Prefix nor an > > > Anycast Prefix. Using the N-flag for a non-/128 would allow us to > > > unambiguously indicate that > > > ::/64 is a Node Prefix, so we can use the associated End-SID > > ::1 > > > in a manner > > > consistent with the knowledge that ::/64 is NOT owned by more > > than > > > one router > > > within the same routing domain. > > > > > > One other small point relates to the statement below that > > "locators are > > > never /128". > > > I don't think it would be very useful to configure a /128 > > locator, since > > > it only has > > > space for one SRv6 SID. However, the current text of > > > draft-ietf-lsr-isis-srv6-extensions explicitly > > > allows the Loc-Size to be 1-128. > > > > ##PP > > agree, but I don't believe we need to put any special text to state > the > > above, it's obvious. > > > > thanks, > > Peter > > > > > > Thanks, > > > Chris > > > > > > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak > <mailto:ppse...@cisco.com> > > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> wrote: > > > > > > Hi Chris, > > > > > > On 03/02/2020 14:39, Peter Psenak wrote: > > > >> I think a reasonable solution would be to remove the > > restriction > > > >> > > > >> on the N-flag to allow it to be used for non-/128 > > > prefixes/locators. This > > > >> > > > >> would allow the three possible prefix-SIDs
Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
All, I'm forwarding this question and subsequent response to the list because it looks like I accidentally sent it only to Peter before. Chris On Fri, Feb 7, 2020 at 4:15 PM Chris Bowers wrote: > Peter, > > Thanks for the clarification. > > Can you also clarify how a receiver should interpret a locator > advertisement that doesn't have a corresponding RFC7794 advertisement? > > Modifying the example below, suppose I receive a locator advertisement > from router R7 with locator = ::/64 and End-SID ::1, but R7 doesn't > originate an RFC7794 advertisement for ::/64. Can I conclude that > ::/64 is not Anycast, so it can be used as a Node-SID when constructing > TE paths as discussed below ? > > Thanks, > Chris > > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak wrote: > >> Hi Chris, >> >> On 04/02/2020 23:17, Chris Bowers wrote: >> > Peter, >> > >> > Suppose I receive a locator advertisement from router R7 with >> > locator = ::/64 and End-SID ::1. I would like to be able to >> use >> > End-SID ::1 as >> > a Node-SID when constructing traffic engineered paths. That is, I want >> > to know that >> > the person or system that configured R7 believes that ::/64 >> > is NOT owned by more than one router within the same routing domain. >> >> ##PP >> sure, if the A-bit is not set, you should be fine to pick the SID from a >> locator. Please see below why. >> >> > >> > Since we are going with Interpretation I) below, a prefix can be (a) a >> > Node Prefix, (b) an Anycast Prefix, >> > or (c) neither of them. >> >> ##PP >> above is correct in general. >> >> However, given that locator is non-/128, N-bit does not apply per >> RFC7794. So for a locator you only have (b) or (c) and you would only >> want to avoid (b) for what you want to do above. >> >> >> > If I receive an RFC7794 advertisement from R7 >> > for ::/64 with N=0, A=0, >> > I can only conclude that ::/64 is either (a) a Node Prefix or (c) >> > neither a Node Prefix nor an >> > Anycast Prefix. Using the N-flag for a non-/128 would allow us to >> > unambiguously indicate that >> > ::/64 is a Node Prefix, so we can use the associated End-SID >> ::1 >> > in a manner >> > consistent with the knowledge that ::/64 is NOT owned by more than >> > one router >> > within the same routing domain. >> > >> > One other small point relates to the statement below that "locators are >> > never /128". >> > I don't think it would be very useful to configure a /128 locator, >> since >> > it only has >> > space for one SRv6 SID. However, the current text of >> > draft-ietf-lsr-isis-srv6-extensions explicitly >> > allows the Loc-Size to be 1-128. >> >> ##PP >> agree, but I don't believe we need to put any special text to state the >> above, it's obvious. >> >> thanks, >> Peter >> > >> > Thanks, >> > Chris >> > >> > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak > > <mailto:ppse...@cisco.com>> wrote: >> > >> > Hi Chris, >> > >> > On 03/02/2020 14:39, Peter Psenak wrote: >> > >> I think a reasonable solution would be to remove the restriction >> > >> >> > >> on the N-flag to allow it to be used for non-/128 >> > prefixes/locators. This >> > >> >> > >> would allow the three possible prefix-SIDs states to be easily >> > represented. >> > > ##PP >> > > right, that could be a possibility, which would allow SRv6 >> locator to >> > > have the "node" property, as locators are never /128. >> > >> > do you have a use case, where the locator would need a N-flag? >> > >> > I can not really think of any, so unless we have one, we better not >> > define an N-flag for a non-/128 locator prefix. >> > >> > thanks, >> > Peter >> > >> > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak > > <mailto:ppse...@cisco.com>> wrote: >> > >> > Hi Chris, >> > >> > adding to what Les has said. >> > Please see inline (##PP) >> > >> > On 31/01/2020 21:10, Chris Bowers wrote: >> > > Peter and Les, >> > > >> >
Re: [Lsr] more feedback on draft-ietf-lsr-isis-srv6-extensions-04
Thanks. The proposed text below looks good to me. Chris On Wed, Feb 5, 2020 at 5:13 AM Peter Psenak wrote: > Hi Chris, > > On 05/02/2020 00:27, Chris Bowers wrote: > > LSR, > > > > I have some more feedback on draft-ietf-lsr-isis-srv6-extensions-04 that > > I am putting in a separate thread so as not to confuse the other thread > > related to N and A flags. > > > > === > > The end of Section 5 points out several issues that can result in > > forwarding not working correctly. The reader might think that the next > > section is going to discuss protocol mechanisms to avoid these issues. > > Since this is not the case, I think it would be helpful to add some text > > near the end of Section 5 like: > > > > "In order to ensure correct forwarding, network operators should take > > steps to make sure that this requirement is not compromised." > > ##PP > sure. > > > > > > > = > > > > In section 6, I think it would be useful to explicitly state the > > following requirement for SRv6 Locator TLVs and their associated SRv6 > SIDs: > > > > > > "When anycast SRv6 Locator TLVs for the same prefix are advertised by > > different nodes, the SRv6 Locator TLVs MUST all advertise identical sets > > of SRv6 SIDs." > > ##PP > here's the proposed text: > > All the nodes advertising the same anycast locator MUST instantiate the > exact same set of SIDs under such anycast locator. > > > > > > > Section 3.3 of RFC 8402 has similar text: "Within an anycast group, all > > routers in an SR domain MUST advertise the same prefix with the same SID > > value." That text only refers to a single SID value, so it seems > > somewhat open to interpretation text in the context of an SRv6 locator > > that carries multiple SRv6 SIDs. I think it would be better to avoid any > > potential ambiguity by using the text proposed above in this document. > > > > = > > > > In section 12.1.2. "Revised sub-TLV table" it might avoid an extra > > interaction with IANA to add a line for the flex-algo prefix metric > > (currently 6) indicating "n" for TLV#27. > > ##PP > flex-algo prefix metric is not defined in this draft, so I don't believe > we can mention it here. > > thanks, > Peter > > > > > == > > > > Thanks, > > > > Chris > > > > > > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] more feedback on draft-ietf-lsr-isis-srv6-extensions-04
LSR, I have some more feedback on draft-ietf-lsr-isis-srv6-extensions-04 that I am putting in a separate thread so as not to confuse the other thread related to N and A flags. === The end of Section 5 points out several issues that can result in forwarding not working correctly. The reader might think that the next section is going to discuss protocol mechanisms to avoid these issues. Since this is not the case, I think it would be helpful to add some text near the end of Section 5 like: "In order to ensure correct forwarding, network operators should take steps to make sure that this requirement is not compromised." = In section 6, I think it would be useful to explicitly state the following requirement for SRv6 Locator TLVs and their associated SRv6 SIDs: "When anycast SRv6 Locator TLVs for the same prefix are advertised by different nodes, the SRv6 Locator TLVs MUST all advertise identical sets of SRv6 SIDs." Section 3.3 of RFC 8402 has similar text: "Within an anycast group, all routers in an SR domain MUST advertise the same prefix with the same SID value." That text only refers to a single SID value, so it seems somewhat open to interpretation text in the context of an SRv6 locator that carries multiple SRv6 SIDs. I think it would be better to avoid any potential ambiguity by using the text proposed above in this document. = In section 12.1.2. "Revised sub-TLV table" it might avoid an extra interaction with IANA to add a line for the flex-algo prefix metric (currently 6) indicating "n" for TLV#27. == Thanks, Chris ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Peter, Suppose I receive a locator advertisement from router R7 with locator = ::/64 and End-SID ::1. I would like to be able to use End-SID ::1 as a Node-SID when constructing traffic engineered paths. That is, I want to know that the person or system that configured R7 believes that ::/64 is NOT owned by more than one router within the same routing domain. Since we are going with Interpretation I) below, a prefix can be (a) a Node Prefix, (b) an Anycast Prefix, or (c) neither of them. If I receive an RFC7794 advertisement from R7 for ::/64 with N=0, A=0, I can only conclude that ::/64 is either (a) a Node Prefix or (c) neither a Node Prefix nor an Anycast Prefix. Using the N-flag for a non-/128 would allow us to unambiguously indicate that ::/64 is a Node Prefix, so we can use the associated End-SID ::1 in a manner consistent with the knowledge that ::/64 is NOT owned by more than one router within the same routing domain. One other small point relates to the statement below that "locators are never /128". I don't think it would be very useful to configure a /128 locator, since it only has space for one SRv6 SID. However, the current text of draft-ietf-lsr-isis-srv6-extensions explicitly allows the Loc-Size to be 1-128. Thanks, Chris On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak wrote: > Hi Chris, > > On 03/02/2020 14:39, Peter Psenak wrote: > >> I think a reasonable solution would be to remove the restriction > >> > >> on the N-flag to allow it to be used for non-/128 prefixes/locators. > This > >> > >> would allow the three possible prefix-SIDs states to be easily > represented. > > ##PP > > right, that could be a possibility, which would allow SRv6 locator to > > have the "node" property, as locators are never /128. > > do you have a use case, where the locator would need a N-flag? > > I can not really think of any, so unless we have one, we better not > define an N-flag for a non-/128 locator prefix. > > thanks, > Peter > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak wrote: > Hi Chris, > > adding to what Les has said. > Please see inline (##PP) > > On 31/01/2020 21:10, Chris Bowers wrote: > > Peter and Les, > > > > It seems to me that for the Node Flag in RFC7794 and the proposed > > Anycast Flag > > > > in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned > with > > > > how to identify IGP-Node Segments and IGP-Anycast Segments, as defined > > in RFC8402, > > > > the Segment Routing Architecture document. > > > > If this is the case, then the following text from RFC8402 is very > relevant. > > > > > > > > 3.2. IGP-Node Segment (Node-SID) > > > > An IGP Node-SID MUST NOT be associated with a prefix that is owned by > > > > more than one router within the same routing domain. > > > > 3.3. IGP-Anycast Segment (Anycast-SID) > > > > > > > > An IGP-Anycast segment MUST NOT reference a particular node. > > > > . > > > > > > > > This text can be interpreted in two different ways. > > > > Interpretation I) > > > > A prefix-SID can have the following three possible states. > > > > Ia) Node-SID > > > > Ib) Anycast-SID > > > > Ic) neither Node-SID nor Anycast-SID > > ##PP > Prefix can either be Node Prefix, Anycast Prefix or neither of them. > > > > > > Interpretation II) > > > > A prefix-SID can have the following two possible states. > > > > IIa) Node-SID > > > > IIb) Anycast-SID > > > > If Interpretation I) is correct, then I think that the current encodings > in > > > > draft-ietf-lsr-isis-srv6-extensions-04 do not allow us > > > > to unambiguously identify a Node-SID for a non-/128 > > > > prefix/locator. For example, the End-SIDs within a /64 locator with the > > A-flag set could > > > > either be Ia) a Node-SID > > ##PP > rfc7794 does not allow the N-flag to be set for non-/128 prefix, so > above is not possible for /64 locator at the moment. > > If the A-flag is set, it is an anycast locator. > > > > >or Ic) neither Node-SID nor Anycast-SID. > > ##PP > if the A-flag was not set for /64 locator, above would be correct, but > given that the A-flag is set, it is clearly just Anycast locator. > > > > > I think a reasonable solution would be to remove the restriction > > > > on the N-flag to allow it to be used for non-/128 prefixes/locators. > This > > > > would allow th
Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Peter and Les, It seems to me that for the Node Flag in RFC7794 and the proposed Anycast Flag in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with how to identify IGP-Node Segments and IGP-Anycast Segments, as defined in RFC8402, the Segment Routing Architecture document. If this is the case, then the following text from RFC8402 is very relevant. 3.2. IGP-Node Segment (Node-SID) An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain. 3.3. IGP-Anycast Segment (Anycast-SID) An IGP-Anycast segment MUST NOT reference a particular node. This text can be interpreted in two different ways. Interpretation I) A prefix-SID can have the following three possible states. Ia) Node-SID Ib) Anycast-SID Ic) neither Node-SID nor Anycast-SID Interpretation II) A prefix-SID can have the following two possible states. IIa) Node-SID IIb) Anycast-SID If Interpretation I) is correct, then I think that the current encodings in draft-ietf-lsr-isis-srv6-extensions-04 do not allow us to unambiguously identify a Node-SID for a non-/128 prefix/locator. For example, the End-SIDs within a /64 locator with the A-flag set could either be Ia) a Node-SID or Ic) neither Node-SID nor Anycast-SID. I think a reasonable solution would be to remove the restriction on the N-flag to allow it to be used for non-/128 prefixes/locators. This would allow the three possible prefix-SIDs states to be easily represented. If Interpretation II) is correct, then I think that the current encodings in draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to how to interpret a /128 prefix/locator advertisement with N=0, A=0. We have to decide between interpreting the End-SIDs within the locator as either Node-SIDs or Anycast-SIDs, since there is no third option. I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0 case is preferable because it preserves backwards compatibility. Thanks, Chris On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak wrote: > Hi Chris, > > please see inline (##PP) > > On 29/01/2020 17:25, Chris Bowers wrote: > > I would like to proposed the following text to make section 6 more clear. > > > > Thanks, > > Chris > > > > > > > > (existing text) > > > > > > 6. Advertising Anycast Property > > > > Both prefixes and SRv6 Locators may be configured as anycast and as > > > > such the same value can be advertised by multiple routers. It is > > > > useful for other routers to know that the advertisement is for an > > > > anycast identifier. > > > > A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV" > > > > registry [RFC7794] is defined to advertise the anycast property: > > > > Bit #: 4 (Suggested - to be assigned by IANA) > > > > Name: Anycast Flag (A-flag) > > > > When the prefix/SRv6 locator is configured as anycast, the A-flag > > > > SHOULD be set. Otherwise, this flag MUST be clear. > > > > The A-flag MUST be preserved when leaked between levels. > > > > The A-flag and the N-flag MUST NOT both be set. > > > > start insert new text === > > > > > > Certain use cases require prefixes/locators that uniquely belong to a > node. > > > > Since prefixes/locators which are not /128 should not have the N bit set, > > > > this node local uniqueness is decided based on A bit for non-/128 > prefixes. > > ##PP > above does not seem correct. Above seems to imply that for non-/128 > prefix, A-bit is replacement of N-bit. > > A-bit applies to both /128 and non-/128 prefixes equally. > > Current draft clearly states what to do when both N a A bits are set. > > > > > > > When a prefix/locator iscategorized as anycast, it does not uniquely > > belong > > > > to a node and cannot be used for such use cases. The rules below > > specify > > > > how to determine whether or not a prefix/locator should be treated > > as anycast > > > > in various situations. > > > > > > [RFC7794] contains the following restriction on the interpretation > of the N-flag. > > > > "If the flag is set and the prefix length is NOT a host prefix > > > > (/32 for IPV4, /128 forIPv6), then the flag MUST be ignored." > > > > The current document does NOT modify this restriction on the > interpretation of > > > > the N-flag imposed by [RFC7794]. >
Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
I would like to proposed the following text to make section 6 more clear. Thanks, Chris (existing text) 6. Advertising Anycast Property Both prefixes and SRv6 Locators may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV" registry [RFC7794] is defined to advertise the anycast property: Bit #: 4 (Suggested - to be assigned by IANA) Name: Anycast Flag (A-flag) When the prefix/SRv6 locator is configured as anycast, the A-flag SHOULD be set. Otherwise, this flag MUST be clear. The A-flag MUST be preserved when leaked between levels. The A-flag and the N-flag MUST NOT both be set. start insert new text === Certain use cases require prefixes/locators that uniquely belong to a node. Since prefixes/locators which are not /128 should not have the N bit set, this node local uniqueness is decided based on A bit for non-/128 prefixes. When a prefix/locator is categorized as anycast, it does not uniquely belong to a node and cannot be used for such use cases. The rules below specify how to determine whether or not a prefix/locator should be treated as anycast in various situations. [RFC7794] contains the following restriction on the interpretation of the N-flag. "If the flag is set and the prefix length is NOT a host prefix (/32 for IPV4, /128 for IPv6), then the flag MUST be ignored." The current document does NOT modify this restriction on the interpretation of the N-flag imposed by [RFC7794]. For a prefix/SRv6 Locator advertisement with a /128 prefix/locator, if both N-flag and A-flag are set, the receiving router MUST treat the prefix advertisement as anycast. For a prefix/SRv6 Locator advertisement with a /128 prefix/locator, if the N-flag and A-flag are NOT set, the receiving routers MUST treat the prefix advertisement as anycast. This rule ensures the correct interpretation of a prefix advertisement originated by a router that is not SRv6 capable and originates a legacy Prefix Attribute Flags Sub-TLV based on [RFC7794] alone. For a prefix/SRv6 Locator advertisement with a prefix/locator that is NOT /128, the N-flag must be ignored, so the setting of the A-flag determines the anycast treatment of the prefix advertisement. The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV as well as the Prefix Reachability TLVs. When a router originates both the Prefix Reachability TLV and the SRv6 Locator TLV for a given prefix, and the router is originating the Prefix Attribute Flags Sub-TLV in one of the TLVs, the router SHOULD advertise identical versions of the Prefix Attribute Flags Sub-TLV in both TLVs. If a router receives one Prefix Attribute Flags Sub-TLV in the Prefix Reachability TLV and another in the SRv6 Locator TLV, the router should use the prefix attribute flags received in the Prefix Reachability TLV. If a router receives a Prefix Attribute Flags Sub-TLV in the Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should use the prefix attribute flags received in the Prefix Reachability TLV. If a router receives a Prefix Attribute Flags Sub-TLV in the SRv6 Locator TLV but not in the Prefix Reachability TLV, the router should use the prefix attribute flags received in the SRv6 Locator TLV. end insert new text = The same prefix/SRv6 Locator can be advertised by multiple routers. If at least one of them sets the A-Flag in its advertisement, the prefix/SRv6 Locator SHOULD be considered as anycast. === On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps wrote: > This begins a 2 week WG Last Call, ending after Feb 4, 2020, for > draft-ietf-lsr-isis-srv6-extensions > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ > > Authors please indicate if you aware of any other IPR beyond what is > posted: > > https://datatracker.ietf.org/ipr/3796/ > > Thanks, > Chris & Acee. > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
