Well, we have the AnyCast flag for IS-IS today but we don’t have configuration in IS-IS.
Peter, Ketan - how does this work today for Cisco IS-IS today? > On Sep 10, 2025, at 12:52 PM, Yingzhen Qu <[email protected]> wrote: > > 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. If the prefix is an anycast prefix, then it would seem to make sense to advertise it as such, Thanks, Acee > > Thanks, > Yingzhen > > On Wed, Sep 10, 2025 at 8:56 AM Acee Lindem <[email protected] > <mailto:[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] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Ran, >> > Please see zzh> below. >> > >> > Juniper Business Use Only >> > From: [email protected] <mailto:[email protected]> >> > <[email protected] <mailto:[email protected]>> >> > Sent: Tuesday, September 9, 2025 10:28 PM >> > To: Jeffrey (Zhaohui) Zhang <[email protected] >> > <mailto:[email protected]>> >> > Cc: [email protected] <mailto:[email protected]>; >> > [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] <mailto:[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] >> > <mailto:[email protected]>> >> > To: [email protected] <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>; >> > Cc: [email protected] >> > <mailto:[email protected]> >> > <[email protected] >> > <mailto:[email protected]>>;[email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>;[email protected] >> > <mailto:[email protected]><[email protected] <mailto:[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] <mailto:[email protected]> >> > To unsubscribe send an email to [email protected] >> > <mailto:[email protected]> >> >>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
