Hi Gunter,
Thank you very much for this review. Your detailed feedback and guidance were
instrumental in refining the draft.
I would also like to specifically thank Acee for his excellent help in
clarifying the implementation and operational context of the Anycast Flag,
which helped address your core technical concerns.
Following your request, I have completed the two necessary editorial
corrections:
The unused reference to 'I-D.ietf-rtgwg-segment-routing-ti-lfa' has been
removed.
The unused reference to 'RFC8402' has been removed.
I am pleased to confirm that Revision -08 of the draft, including these
changes, has now been submitted and uploaded to the IETF website
https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/.
Best regards,
Ran
Original
From: GuntervandeVelde(Nokia) <[email protected]>
To: Acee Lindem <[email protected]>;
Cc: [email protected]
<[email protected]>;lsr <[email protected]>;
Date: 2025年11月17日 17:56
Subject: [Lsr] Re: [Shepherding AD review] review of
draft-ietf-lsr-anycast-flag-07
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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]> wrote:
Hi Acee,
Inline: GV2>
-----Original Message-----
From: Acee Lindem <[email protected]>
Sent: Friday, November 14, 2025 5:00 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.
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.
IS-IS TLV Codepoints
iana.org
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]
