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]
