Speaking as document shepherd: Hi Ketan,
> On Sep 11, 2025, at 3:27 AM, Ketan Talaulikar <[email protected]> wrote: > > < speaking as co-author > > > Hi Acee, > > I am OK with leaving the AC flag out of the YANG model for now if this is > something that needs further discussion. And just cover the LSDB part. I suggested this since I’m sure the IGPs are the correct place. You DID NOT answer my question though. We’ve had the anycast flag for IS-IS for some time now? How does IS-IS know whether or not a prefix is anycast? How is this configured/determined in Cisco Network OSs? > > Coming to your point, from a provisioning perspective, we are mostly dealing > with prefixes configured on the router interfaces (especially loopback is of > interest) which can have N-flag (uniquely identifies the node), or AC-flag > (indicates it is anycast), or nothing which was the original situation and > doesn't convey anything explicitly (but may be used in certain ways depending > on the use case). Therefore, the current proposal from Yingzhen to tie > AC-flag to interfaces makes sense to me. > > This does not preclude the anycast property being set on other prefixes being > originated by the router into an OSPF domain (e.g., via redistribution) - > those may need a different configuration mode than interface (perhaps at the > node level or even outside OSPF?). If it is outside OSPF (and ISIS) then > perhaps it should be under some common routing mode? Is it ok to do that in > this OSPF document in LSR? > > To proceed further, I see the following options: > a) we skip the provisioning of the AC-flag in this document and let us > conclude the discussion and then make necessary changes for both OSPF and > ISIS in a different model > b) add the interface mode (as proposed by Yingzhen) for now and leave the > other mode out since it might be outside OSPF I think the above question needs to be answered in the context of both IS-IS and OSPF. Thanks, Acee > > Thanks, > Ketan > > > On Wed, Sep 10, 2025 at 11:03 PM Acee Lindem <[email protected] > <mailto:[email protected]>> wrote: >> 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] >>> <mailto:[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]
