Hi Acee,
The plan is to update the version ahead of schedule in the next couple of days.
Thanks for the reminder.
BR,
Ran
Original
From: AceeLindem <[email protected]>
To: 陈然00080434;
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
Date: 2025年12月07日 20:55
Subject: [Lsr] Re: [Last-Call] draft-ietf-lsr-anycast-flag-08 ietf last call
Secdir review
Speaking as Document Shepherd:
Hey Ran,
When can we expect to see these updates in the draft?
Thanks,
Acee
> On Nov 26, 2025, at 3:00 AM, [email protected] wrote:
>
> 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]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
