Hi Acee, Thanks, your elaboration on prefixes and non-existence of the flag makes sense. Once the unused references are removed I’ll progress the document to next step in the pipeline.
G/ From: Acee Lindem <[email protected]> Sent: Friday, November 14, 2025 5:55 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: [email protected]; lsr <[email protected]> Subject: Re: [Shepherding AD review] review of draft-ietf-lsr-anycast-flag-07 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hey Gunter, I understand where you are coming from now… See inline. On Nov 14, 2025, at 11:27 AM, Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Acee, Inline: GV2> -----Original Message----- From: Acee Lindem <[email protected]<mailto:[email protected]>> Sent: Friday, November 14, 2025 5:00 PM To: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: [Shepherding AD review] review of draft-ietf-lsr-anycast-flag-07 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. Hi Gunter, On Nov 14, 2025, at 5:15 AM, Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> wrote: # Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-anycast-flag-07 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/arch ive/id/draft-ietf-lsr-anycast-flag-07.txt # Many thanks for the RTGDIR review from Jeffrey and the shepherd writeup from Acee Lindem. # I found the draft well written, easy to ready and to understand the procedures and have only few observations. # The idnits tool suggest 2 unused references: == Unused Reference: 'I-D.ietf-rtgwg-segment-routing-ti-lfa' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 408, but no explicit reference was found in the text # comments # ======== 119 When a prefix is configured as anycast, the AC-flag MUST be set. 120 Otherwise, this flag MUST be clear. GV > What exactly does “configured as anycast” mean? Does it refer to two routers using the same prefix, or does it require an explicit CLI configuration marking the prefix as anycast? Maybe that should be more explicit clarified in the text. GV > I’m also concerned about operational impact: if a prefix is already used as an anycast and a router is upgraded to a version that supports this draft, could the flag suddenly appear even though it was not previously configured? That could change how the prefix is treated operationally network wide. 128 The same prefix can be advertised by multiple routers, and that if at 129 least one of them sets the AC-flag in its advertisement, the prefix 130 is considered as anycast. GV> Is there an implied assumption here that: "The same prefix can be advertised by multiple routers, and if none of them sets the AC-flag in its advertisement, the prefix SHOULD still be considered as anycast." I don't understand why this would be implied. The assumption is that if none of the routers advertise it as anycast that it shouldn't be considered anycast. GV2> It would be in how "anycast" is understood. In a liberal understanding it would mean when two devices send the same prefix, it is anycast addressing even without any flags or explicit configuration. In the way this specific document prescribes anycast, is that the prefix is only anycast if the flag is explicitly set. All I am trying to go towards is t nail this down in text to avoid confusion. Only if it is a host route (i.e., /32 for IPv4 and /128 for IPv6). As you know, multiple routers can advertise the same subnet routes and it not be an anycast. In the case of host routes, we decided a while ago to allow explicit specification in IS-IS rather than having to keep track of whether the host route has been advertised by multiple routers and this would definitely be lost across multiple areas and multiple protocols. However, the IS-IS anycast flag was introduced in RFC 9352 with SRv6 so it was hardly a blip on anyone’s radar. IS-IS TLV Codepoints<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags> iana.org<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags> [cid:[email protected]]<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags> I think we are over thinking this and we definitely shouldn’t say anything about a prefix not being considered an anycast. There will also be routers that don’t support this flag (indefinitely). Thanks, Acee Be well, G/ Thanks, Acee GV> If this is the intent, it should be stated explicitly. If not, the text risks being interpreted that way and may need a formal statement that such condition should not be interpreted this way. Maybe this something intentionally left open for implementors to decide upon? Many thanks for this well written document, Kind Regards, Gunter Van de Velde RTG Area Director
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
