Hi Acee, Inline: GV>
-----Original Message----- From: Acee Lindem <[email protected]> Sent: Thursday, December 11, 2025 1:03 PM To: [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected]; last-call <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] [Last-Call] draft-ietf-lsr-anycast-flag-08 ietf last call Secdir review CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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/ GV> yes. I'll remind the reviewer. However I have now requested IESG ballot review to keep moving forward G/ 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]
