Hi Wes，
Many thanks for your review! Please see inline...
BR，
Ran
Original
From: WesHardakerviaDatatracker <[email protected]>
To: [email protected] <[email protected]>;
Cc: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
Date: 2025年11月24日 23:39
Subject: [Last-Call] draft-ietf-lsr-anycast-flag-08 ietf last call Secdir review
Document: draft-ietf-lsr-anycast-flag
Title: OSPFv2 Anycast Property Advertisement
Reviewer: Wes Hardaker
Review result: Has Nits
# 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.
>Ran: I appreciate the recognition. The following content will be added to
the second paragraph of the security consideration section:
The newly introduced AC flag, which MUST be either set or clear, introduces
operational dependencies that impact the semantic validity of the advertised
prefix. The correct semantic interpretation of the AC flag relies on both
router implementation support for the bit and accurate operator configuration
of the anycast route. Consequently, receivers MUST consider the possibility
of misconfiguration or inconsistent implementation when relying on the AC
flag for forwarding or security decisions.
Please check if this addresses your concerns.
# 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.]
>Ran: This motivation and usecase were actually present in an earlier version
>of
our draft (please refer to version 06). However, we subsequently removed this
content based on feedback and consensus reached during the RTG Area review
process. The primary reason is that this functionality is already supported and
implemented in related protocols like OSPFv3 [RFC9513] and ISIS [RFC9352].
Also note that rfc8402 might be a slightly better or second reference for
anycast
segments than 9085.
>Ran:Thank you for your suggestion regarding the reference to RFC 8402. We
>believe
the current references are adequate based on the foundational principle that the
anycast property applies to any IP prefix advertisement, and is not limited to
the
Segment Routing context.
We confirm that our reference to [RFC9085], which defines the Prefix Attribute
Flags TLV for BGP-LS that carries prefix attribute flags information, remains
necessary and sufficient for the current scope.
- The N-flag doesn't have a reference but probably should (RFC3101)
>Ran: Thank you for pointing this out.The N-flag reference citation will be
>added.
section2:
Original content: The AC-flag and the N-bit MUST NOT both be set. If both
N-flag and AC-flag are set, the receiving routers MUST ignore the N-flag.
Updated content: The AC-flag and the N-flag (section 2.1 of [RFC7684]) MUST NOT
both be set. If both N-flag and AC-flag are set, the receiving routers MUST
ignore the N-flag.
- 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?
>Ran:This flag utilizes the existing mechanism defined in RFC 9085, which
>specifies
the BGP-LS Prefix Attribute Flags TLV for reporting IGP prefix flags.
- 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.
>Ran: Good point. We will make that adjustment to Section 7.1(It should be
>Section 7.1, not Section 5.1, right?).
This document requests the allocation of new value in the "OSPFv2 Extended
Prefix TLV Flags" registry:
TBD: AC-flag (Anycast Flag).
# Nits
- Last sentence of section 2: "is considered node-specific prefix" -> "is
considered *a* node-specific prefix"
>Ran: Thanks. Will update in next version.
--
last-call mailing list -- [email protected]
To unsubscribe send an email to [email protected]_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
