Hi Gunter, > 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.
Not necessarily, both end of a point-to-point link will specify the link’s subnet. For inter-area routes, all the ABRs will advertise the prefix. This certainly doesn’t make the prefix anycast. > 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. How come you clipped my previous response? I don’t like when people do that 🤨 The point I was making in the text that you clipped is that this draft allows a way to explicitly specify that a prefix an anycast address. If no routers advertising the prefix set the flag, you don’t know and I don’t think this needs to be in the draft. 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]
