Hi, For the RTGDIR review, I basically made some editorial comments and raised a doubt about the YANG model. I am glad to see the good discussions on the latter. I consider my review closed – whichever option we proceed with is fine by me after the authors/experts agree on it.
Thanks. Jeffrey Juniper Business Use Only From: Ketan Talaulikar <[email protected]> Sent: Thursday, September 11, 2025 3:28 AM To: Acee Lindem <[email protected]> Cc: Peter Psenak <[email protected]>; Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]; Routing Directorate <[email protected]>; [email protected]; last-call <[email protected]>; lsr <[email protected]>; Yingzhen Qu <[email protected]> Subject: Re: [Last-Call] draft-ietf-lsr-anycast-flag-05 ietf last call Rtgdir review [External Email. Be cautious of content] < 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. 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 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]<mailto:[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]
