As document shepherd: Hi Wes,
Please assure this version satisfies your comments. Hi Gunter, It looks like we're still waiting on the GENART review? https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/ Thanks, Acee > On Dec 11, 2025, at 2:04 AM, [email protected] wrote: > > Hi Acee, > > We have updated the draft based on the reviewers' comments, and please see > the link https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/. > > BR, > Ran > > Original > From: 陈然00080434 > To: AceeLindem <[email protected]>; > 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月08日 09:07 > Subject: Re: [Lsr] Re: [Last-Call] draft-ietf-lsr-anycast-flag-08 ietf last > call Secdir review > Hi Acee, > The plan is to update the version ahead of schedule in the next couple of > days. Thanks for the reminder. > > BR, > Ran > > 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]
