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 <chrisbowers.i...@gmail.com> 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 = 7777::/64 and End-SID 7777::1, but R7 doesn't > originate an RFC7794 advertisement for 7777::/64. Can I conclude that > 7777::/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 <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 = 7777::/64 and End-SID 7777::1. I would like to be able to >> use >> > End-SID 7777::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 7777::/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 7777::/64 with N=0, A=0, >> > I can only conclude that 7777::/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 >> > 7777::/64 is a Node Prefix, so we can use the associated End-SID >> 7777::1 >> > in a manner >> > consistent with the knowledge that 7777::/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 <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 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 <ppse...@cisco.com >> > <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, >> > > >> > > 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 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. >> > >> > thanks, >> > Peter >> > >> > >> > > >> > > 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 <ppse...@cisco.com >> > <mailto:ppse...@cisco.com> >> > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> 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]. >> > > >> > > ##PP >> > > I don't think above text is needed. And I don't think above >> is >> > > completely correct, as we define a new case in which the >> N-bit >> > > should be >> > > ignored (when A-bit is set). >> > > >> > > >> > > > >> > > > 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. >> > > >> > > ##PP >> > > we have following text in the draft already: >> > > >> > > "If both N-flag and A-flag are set in the prefix/SRv6 Locator >> > > advertisement, the receiving routers MUST ignore the >> > N-flag." >> > > >> > > >> > > >> > > > >> > > > 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.. >> > > >> > > ##PP >> > > I don't think above statement is correct. Why a node cannot >> > advertise a >> > > /128 prefix which is not an anycast one and does not have a >> > N-bit set? >> > > >> > > >> > > >> > > > 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. >> > > >> > > ##PP >> > > A-flag does that regardless of the length of the prefix. >> > > >> > > >> > > > >> > > > 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. >> > > >> > > ##PP >> > > Above seems a good suggestion. Will add it. >> > > >> > > > >> > > > >> > > > >> > > > 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. >> > > >> > > ##PP >> > > above contradicts what you suggest in the previous paragraph, >> > where you >> > > suggest we need to advertise with both prefix and locator, >> > and here you >> > > suggest we ignore what we received in the locator. >> > > >> > > Are you talking about the case where the content of the >> Prefix >> > > Attribute >> > > Flags Sub-TLV is different in prefix vs locator? >> > > > >> > > > >> > > > >> > > > 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. >> > > >> > > ##PP >> > > do we really need this? If the originator does the right >> > thing, then we >> > > don't have the problem. Cross referencing data between >> > different TLVs >> > > complicates the implementations. >> > > >> > > >> > > > >> > > > >> > > > >> > > > 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. >> > > >> > > ##PP >> > > same as above. >> > > >> > > thanks, >> > > Peter >> > > >> > > > >> > > > ==== 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 >> > > <cho...@chopps.org <mailto:cho...@chopps.org> >> > <mailto:cho...@chopps.org <mailto:cho...@chopps.org>> >> > > > <mailto:cho...@chopps.org <mailto:cho...@chopps.org> >> > <mailto:cho...@chopps.org <mailto:cho...@chopps.org>>>> 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/ >> > > > >> > > >> > < >> 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 <mailto: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>>> >> > > > https://www.ietf.org/mailman/listinfo/lsr >> > > > >> > > >> > >> >>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
