# 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/archive/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."
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]
