< 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]> 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]> 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]
