Hmm … I am curious why we even need an interface-level node-flag in the YANG model. Shouldn’t all local addresses on an interface carry the N-flag? Or is there a good reason to not signal the N-flag for all local addresses?
Jeffrey Juniper Business Use Only From: Ketan Talaulikar <[email protected]> Sent: Thursday, September 4, 2025 11:46 PM To: Yingzhen Qu <[email protected]> Cc: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-lsr-anycast-flag-05 ietf last call Rtgdir review [External Email. Be cautious of content] < as a WG member and co-author > Hi Yingzhen, I agree with you that the ac-flag is similar to the node-flag in RFC9129. Thanks, Ketan On Fri, Sep 5, 2025 at 4:59 AM Yingzhen Qu <[email protected]<mailto:[email protected]>> wrote: Hi Jeffrey, Thanks for the review. I will answer only the questions to the data model and leave the rest to the authors. " augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface: +--rw anycast-flag? boolean Should it be part of the interface or prefix configuration? An interface could have multiple addresses, and maybe only one/some of them may need the AC-flag? " I thought about this. When a prefix is configured as an anycast address, most likely it's a prefix on a loopback interface, that's why I have this configuration on an interface. Otherwise we can have it in the router mode with a prefix. Please let me know what you think. " prefix ospf-anycast-flag; What does "prefix ospf-anycast-flag" mean here? Is it an interface or prefix property? The following mentions both interface and prefix. " This is just a YANG model's prefix. Thanks, Yingzhen On Thu, Sep 4, 2025 at 1:19 PM Zhaohui Zhang via Datatracker < [email protected]<mailto:[email protected]>> wrote: > Document: draft-ietf-lsr-anycast-flag > Title: OSPFv2 Anycast Property Advertisement > Reviewer: Zhaohui Zhang > Review result: Has Nits > > For the following two paragraphs: > > [RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) > tuples that can be used to associate additional attributes with > prefixes or links. The OSPFv2 Extended Prefix TLV that is contained > in the OSPFv2 Extended Prefix Opaque LSA is used to advertise > additional attributes associated with an IPv4 prefix, but the > definition of anycast flag to identify the IPv4 prefix as anycast has > not yet been defined. > > The flags field of the OSPFv2 Extended Prefix TLV (Section 2.1 of > [RFC7684]) can be found in "OSPFv2 Extended Prefix TLV Flags" IANA > registry [IANA-OSPFv2-EPF]. > > They could be combined into the following: > > [RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) > tuples that can be used to associate additional attributes with > prefixes or links. The OSPFv2 Extended Prefix TLV that is contained > in the OSPFv2 Extended Prefix Opaque LSA is used to advertise > additional attributes associated with an IPv4 prefix, including a flags > field (Section 2.1 of [RFC7684]) with an "OSPFv2 Extended Prefix TLV > Flags" > IANA registry [IANA-OSPFv2-EPF]. > > This would match the changes in the abstract (between the -04 and -05 > revision) > of this draft. > > 2. Use-case > > In the absence of the N-flag, the node specific prefixes need to be > identified from the anycast prefixs. A prefix that is advertised by > a single node and without an Anycast Flag (AC-flag) MUST be > considered node specific. > > The above is not a use case, and the content is present below anyway. > I would suggest to remove the section, or give a real use case example. > I have one in mind and could provide text if you would like to include it
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
