Hi Ran, Sounds good. Thanks, Acee > On Aug 27, 2025, at 2:20 AM, [email protected] wrote: > > Hi Acee， > Thank you very much for requesting the YANG doctor review on our draft. I'll > complete the addition of the YANG section to the draft this week. > Regarding the anycast use case, I will follow up with Ketan next week to > discuss and confirm the content. > > Best regards, > Ran > > Original > From: AceeLindem <[email protected]> > To: [email protected] > <[email protected]>; > Cc: lsr <[email protected]>;Yingzhen Qu <[email protected]>; > Date: 2025年08月27日 06:53 > Subject: [Lsr] Re: WG Group Last Call on "Updates to Anycast Property > advertisement for OSPFv2" - draft-ietf-lsr-anycast-flag-03 > I've requested a YANG doctors review on this draft so it would be good if > someone added the YANG section with the provided augmentations. > > I'm also hoping Ketan will finally add the use case for knowledge of whether > or not a given prefix is an anycast address. > > Thanks, > Acee > > > On Aug 25, 2025, at 7:07 PM, Acee Lindem <[email protected]> wrote: > > > > Authors, > > > > Please add the YANG data module provided by Yingzhen to the draft. You can > > use > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/ > > <https://datatracker.ietf.org/doct-ietf-lsr-ospf-ls-link-infinity/> as an > > example. Note that > > in addition to Section 5 there are additions required to the "Security > > Considerations" relative to > > the YANG data model. > > > > Thanks, > > Acee > > > >> On Aug 25, 2025, at 3:23 PM, Yingzhen Qu <[email protected]> wrote: > >> > >> Hi, > >> > >> I've reviewed the document and have the following comments for the authors > >> to consider. > >> > >> How about changing the title of the document to "OSPFv2 Anycast Property > >> Advertisement"? > >> > >> 21 Each OSPF prefix is advertised along with an 8-bit field of > >> 22 capabilities, by using the flag flield in the OSPFv2 Extended Prefix > >> 23 TLV, but the definition of anycast flag to identify the IPv4 prefix > >> 24 as anycast has not yet been defined. > >> I don't think we need this in the Abstract. > >> > >> 90 The Flags field of the OSPFv2 Extended Prefix TLV (Section 2.1 of > >> 91 [RFC7684]) has 5 unassigned bits remaining (see "OSPFv2 Extended > >> 92 Prefix TLV Flags" IANA registry [IANA-OSPFv2-EPF]). > >> Suggested text: > >> The flags field of he OSPFv2 Extended Prefix TLV (Section 2.1 of > >> [RFC7684]) can be found in "OSPFv2 Extended > >> Prefix TLV Flags" IANA registry [IANA-OSPFv2-EPF]. > >> > >> 94 This document updates [RFC7684], by defining a new flag in the OSPFv2 > >> 95 Extended Prefix TLV Flags [RFC7684] to advertise the anycast property > >> 96 for an IPv4 prefix. > >> This document doesn't update RFC7684. > >> Suggested text: > >> This document defines a new flag in the OSPFv2 > >> Extended Prefix TLV Flags [RFC7684] to advertise the anycast property > >> for an IPv4 prefix. > >> > >> 106 2. Use-case > >> > >> 108 In the absence of the N-flag, the node specific prefixes need to be > >> 109 identified from the anycast prefixs. A prefix that is advertised by > >> 110 a single node and without an AC-flag MUST be considered node > >> 111 specific. > >> The use case needs to be collaborated with more details. > >> Question: > >> "A prefix that is advertised by a single node and without an AC-flag MUST > >> be considered node specific." > >> I don't understand this sentence. Router A supporting what's defined in > >> this document may receive advertisement from Router B which doesn't > >> support AC-flag. Router B will advertise an anycast prefix without > >> AC-flag. What difference will this "MUST" do? > >> nit: AC-flag is used for the first time in the document without any > >> explanation. > >> > >> 113 3. Updates to Anycast Property advertisement for OSPFv2 > >> Please consider: OSPFv2 Anycast Property Advertisement > >> > >> 120 prefix, and it has been defines the below flags(see "OSPFv2 Extended > >> s/it has been defines/it has defined > >> > >> 142 When the prefix is configured as anycast, the AC-Flag SHOULD be set. > >> s/the prefix/a prefix > >> > >> 155 A prefix that is advertised by a single node and without an AC-flag > >> 156 MUST be considered node specific prefix. > >> same question as above. > >> > >> I'm attaching a YANG module and its tree. The module adds the ac-flag > >> definition and configuration of a prefix as anycast. Please let me know if > >> you have any questions. > >> > >> Thanks, > >> Yingzhen > >> > >> > >> > >> On Thu, Aug 14, 2025 at 2:59 AM Acee Lindem <[email protected]> wrote: > >> LSR WG, > >> > >> This begins a 2-week WG last call on draft-ietf-lsr-any-flag-03. Please > >> indicate your support or objection to this list prior to Friday, August > >> 29h, 2025. > >> > >> Thanks, > >> Acee > >> _______________________________________________ > >> Lsr mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >> <ietf-ospf-anycast-flag.yang><ietf-ospf-anycast-flag.tree> > > > > _______________________________________________ > 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]
