IETF Last Call Review of draft-ietf-lsr-anycast-flag-08
review-ietf-lsr-anycast-flag-08-secdir-lc-hardaker-2025-11-24-00

# Overall

Nice and consist document that is well written.

# Security considerations

- The newly introduced AC flag states that it MUST be set or MUST be clear. 
However, this setting is both dependent upon whether an OSPF router supports
the bit in the first place, and additional requires an operator to have
properly configured the route as anycast.  Thus, the value cannot actually be
completely trustable.  I would mention this in the security consideration
section at a minimum.

# Other considerations

- The document doesn't provide motivation for why this flag is needed -- IE,
how would a router receiving the flag act differently?  This
information/rational isn't needed, but may be helpful for the reader.  [One
possible motivation (based on my own experience) might be to ensure outgoing
routes beyond that had the same priority/etc to get load balancing and/or
alternate paths properly considered "equal" and that a router receiving
multiple anycast routes shouldn't drop one as they're all valid.]  Also note
that rfc8402 might be a slightly better or second reference for anycast
segments than 9085.

- The N-flag doesn't have a reference but probably should (RFC3101)

- There is no discussion about passing of the new AC-flag to other protocols. 
EG, section 3 talks about the BGP-LS prefix attribute flags but the document
doesn't provide guidance about how the two protocols should interact when one
carries the flag.  EG, if I have multiple OSPF backends advertising the
AC-flag, should that carry over to the outgoing (E)BGP announcement?

- It would be nice if 5.1 was modified by the RFC editor and IANA to include
the newly assigned bit value, rather than having the reader need to refer to
the IANA assignment.  IE, put in text saying that it's bit TBD and let IANA and
the editor fill it out when assignment is completed.

# Nits

- Last sentence of section 2:  "is considered node-specific prefix" -> "is
considered *a* node-specific prefix"