If we make the configuration of anycast an addition of property for IP prefixes, how does OSPF know when to propagate this information? or always do if a prefix is anycast? Instead of interface configuration, we can move this configuration of anycast prefix to router mode.
Thanks, Yingzhen On Wed, Sep 10, 2025 at 8:56 AM Acee Lindem <[email protected]> wrote: > Speaking as WG member: > > I certainly don't think the addition of this the AnyCast flag should drive > interface prefix-configuration into the IGP YANG models. As an author of > RFC 9129 > > Addition of the Any-Cast property for IP prefixes could be considered as > augmentation to ietf-ip.yang (RFC 8344) but need not be part of this draft. > > For this simple draft, the best solution is to remove the OSPF interface > configuration (but retain the LSA encoding) in the YANG augmentation. > > Thanks, > Acee > > > On Sep 10, 2025, at 9:33 AM, Jeffrey (Zhaohui) Zhang <[email protected]> > wrote: > > > > Hi Ran, > > Please see zzh> below. > > > > Juniper Business Use Only > > From: [email protected] <[email protected]> > > Sent: Tuesday, September 9, 2025 10:28 PM > > To: Jeffrey (Zhaohui) Zhang <[email protected]> > > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > > Subject: Re: [Last-Call] draft-ietf-lsr-anycast-flag-05 ietf last call > Rtgdir review > > [External Email. Be cautious of content] > > Hi Jeffery, > > Many thanks for your review! Please see inline... > > BR, > > Ran > > From: ZhaohuiZhangviaDatatracker <[email protected]> > > To: [email protected] <[email protected]>; > > Cc: [email protected] < > [email protected]>;[email protected] < > [email protected]>;[email protected]<[email protected]>; > > Date: 2025年09月05日 04:20 > > Subject: [Last-Call] draft-ietf-lsr-anycast-flag-05 ietf last call > Rtgdir review > > 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. > > Ran: Thank you for your suggestions. We've incorporated your feedback > and made the following revisions. Please let us know if this addresses your > concerns. > > [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 a prefix. > > Extensions related to the anycast property of prefixes have been > > specified for IS-IS [RFC9352] and OSPFv3 [RFC9513], even though those > > documents are related to Segment Routing over IPv6, the anycast > > property applies to any IP prefix advertisement. This document > > defines a flag to advertise the anycast property for a prefix > > advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended > > Prefix TLV Flags (section 2.1 of [RFC7684]). > > Zzh> If this is just a parity feature for OSPFv2, then perhaps we don’t > need the use-case section 😊 > > > > 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. > > Ran: Many thanks! Ketan provided a use case, which we authors have > discussed. > > Please see if the following content is suitable. > > Zzh> Perhaps make it clear that two use cases are included here. > > Section 3.3 of [RFC8402] describes an IGP-Anycast Segment and its use > > with SR-MPLS. The use of an anycast segment as a waypoint in a SR TE > > path is a use-case that requires consistent use of labels both for > > the anycast segment but also the segment following it if that is an > > adjacency SID or binding SID allocated dynamically or from the SRLB. > > However, there is no indication available in OSPFv2 to convey to the > > entity performing path computation using the OSPF LSDB that specific > > prefix segments are anycast segments. > > Zzh> Perhaps remove “is a use-case that”. > > When computing TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] repair > > paths using SR segments, the requirement is to pick specific nodes > > that need to be traversed to ensure loop free characteristics. This > > requires picking prefix segments of those nodes that uniquely > > identify those nodes. The selection of anycast prefix segments > > advertised by those nodes for the TI-LFA repair path may result in > > loops as the traffic may get rerouted to another node advertising the > > same anycast segment. Hence, only node segments (with or without the > > N-flag) and not anycast segments (with the AC-flag) are to be used > > for TI-LFA repair paths. > > > > A prefix that is advertised by a single node and without an AC-flag > > MUST be considered node specific prefix. > > Ran: This sentence wants be be changed to: > > A prefix that is advertised by a single node and without an AC-flag > > is considered node-specific prefix. > > What if a prefix is advertised by multiple nodes but w/o the AC-flag? > > Ran: A prefix advertised by multiple nodes without an AC-flag is > considered an anycast prefix. > > Zzh> Then why do we need the AC-flag? Should we say that any prefix w/o > the AC-flag must not be considered as anycast? > > Zzh> Thanks. > > Zzh> Jeffrey > > > > 5. YANG Data Model > > > > module: ietf-ospf-anycast-flag > > > > 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? > > Ran：Yingzhen and Ketan are already handling the issue. > > > > 5.2. YANG Data Model for OSPFv2 Anycast Property Advertisement > > > > The following is the YANG module: > > > > <CODE BEGINS> file "[email protected]" > > module ietf-ospf-anycast-flag { > > yang-version 1.1; > > namespace > > "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag"; > > 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. > > > > import ietf-routing { > > prefix rt; > > reference > > "RFC 8349: A YANG Data Model for Routing > > Management (NMDA Version)"; > > } > > import ietf-ospf { > > prefix ospf; > > reference > > "RFC 9129: YANG Data Model for the OSPF Protocol"; > > } > > > > identity ac-flag { > > base ospf:ospfv2-extended-prefix-flag; > > description > > "Anycast flag. When set, it indicates that the prefix > > is configured as anycast."; > > } > > > > /* Configuration */ > > augment "/rt:routing/rt:control-plane-protocols/" > > + "rt:control-plane-protocol/ospf:ospf/" > > + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" { > > when "derived-from(/rt:routing/rt:control-plane-protocols/" > > + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { > > description > > "This augments the OSPFv2 interface configuration."; > > } > > description > > "This augments OSPFv2 interface configuration with anycast > > property advertisement."; > > leaf anycast-flag { > > type boolean; > > default "false"; > > description > > "Sets the prefix as an anycast address."; > > } > > } > > } > > > > Thanks. > > Jeffrey > > > > > > > > -- > > 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]
