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]> 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]> 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. 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]
