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 <ppse...@cisco.com> 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 = 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 ? > > 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 <ppse...@cisco.com > > <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 = 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> > > > <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 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> > > > <mailto: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>> > > > > <mailto: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>>> > > > > > <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 <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>>> > > <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 <mailto:Lsr@ietf.org>>>> > > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
