Hi Peter - I knew I could depend on you š > On Sep 18, 2025, at 11:05āÆAM, Peter Psenak <[email protected]> wrote: > > Hi Acee, > > On 18/09/2025 16:32, Acee Lindem wrote: >> Speaking as a WG member: >> >>> On Sep 18, 2025, at 9:51āÆAM, Robert Raszuk <[email protected]> wrote: >>> >>> Hi Ketan, >>> >>> One comment from me on your statement: >>> >>>> The AC-flag simply indicates that the prefix has been configured as >>>> anycast - i.e. originated by multiple routers. >> I've asked several times where and how this is configured for a prefix since >> we've had the IS-IS Anycast prefix flag for some time. However ,heretofore, >> my inquires have been met with passive aggressiveness by the authors. > > Example from one implementation: > > router isis 1 > interface Loopback0 > prefix-attributes anycast
Ok - than this would support keeping the config in the OSPF YANG model as Yingzhen has proposed. Authors, letās keep it there. Thanks, Acee > > thanks, > Peter > >> >> Thanks, >> Acee >> >> >>> IMO making any assumption and therefore any actions just based on the >>> configuration is fundamentally a bad design. The prefix may have been >>> configured as anycast 1 hour ago on two nodes, but since then only one node >>> is active and only one node is advertising it. >>> >>> So how useful is such a flag ? It is only confusing. Treat this as my >>> comment in respect to such flag in OSPFv2, OSPFv3 or ISIS. >>> >>> Thx, >>> Robert >>> >>> >>> >>> On Wed, Sep 17, 2025 at 2:20āÆPM Ketan Talaulikar <[email protected]> >>> wrote: >>> < as a co-author > >>> >>> Hi Bruno, >>> >>> Please check inline below. >>> >>> >>> On Wed, Sep 17, 2025 at 2:15āÆPM <[email protected]> wrote: >>> Thanks Acee, Chen, Ketan, >>> Thanks for the addition and clarification. >>> ā¢ Ketan has added the use-cases you were looking for >>> Iām not looking for use-cases. >>> >>> KT> Thanks. We've got another comment from the RTGDIR reviewer (Jeffrey) to >>> take the use-cases out. We (authors) will take that section on use-cases >>> out unless we get feedback to retain/keep that section. >>> I was looking, and Iām still looking for a normative definition of the >>> semantic associated to the anycast signaling. In particular: >>> ā¢ What are the required conditions for the node advertising the AC flag >>> >>> >>> KT> Sec 1 says "An IP prefix may be configured as anycast and as such the >>> same value can be advertised by multiple routers." >>> ā¢ What are the properties that may be used by the nodes reading the >>> AC flag. >>> >>> >>> KT> Just the part that the prefix may be originated by more than one node >>> and does not uniquely identify a single node. >>> You seem to refer to RFCs 9352, 9513, 9402. But those RFCs have specific >>> text about those conditions/properties, while your document does not. >>> e.g. āAll the nodes advertising the same anycast locator MUST instantiate >>> the exact same set of SIDs under that anycast locator.ā >>> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert >>> https://datatracker.ietf.org/doc/html/rfc9513#name-advertisement-of-anycast-pr >>> āWithin an anycast group, all routers in an SR domain MUST advertise the >>> same prefix with the same SID value.ā >>> https://datatracker.ietf.org/doc/html/rfc8402 >>> ā¢ Iām looking for a similar text in your document. And if you want to >>> make it general (encompassing SR-MPLS, SRv6, MPLS without SR, IP without >>> SRā¦), the definition also needs to be general. >>> >>> >>> KT> This document is simply advertising the property of the prefix and >>> nothing else. Therefore, it cannot make general statements about other >>> things. Those other documents also specified other aspects (SRv6 Locators, >>> SRv6 SIDs, and Prefix SIDs) and so could say more. >>> Whatās worse, your definition/use of the anycast flag seems to be >>> different from the one in the above RFCs: >>> ā¢ Above RFC uses anycast as a āpositiveā signaling. i.e., one may use >>> this anycast prefix/segment because the next segment/header will be >>> consistently used on all the anycast nodes. In particular, the TI-LFA PLR >>> may use those anycast prefix. >>> >>> >>> KT> I am not sure which text in existing RFCs says that anycast prefix may >>> be used by the TI-LFA PLR in its repair path. >>> ā¢ Your draft seems to use anycast as a ānegativeā signaling. i.e., >>> donāt use this prefix as itās anycast and next segment/header may not be >>> consistent. Quoting your usecase ā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.ā >>> >>> >>> KT> I do not follow this connotation of positive or negative here. Some >>> use-cases will look for and use anycast segments while others will avoid >>> using them. The AC-flag simply indicates that the prefix has been >>> configured as anycast - i.e. originated by multiple routers. Both RFCs 9352 >>> and 9513 enabled the signaling of this anycast property of prefixes in >>> IS-IS and OSPFv3 - so, I am failing to understand what is the concern with >>> doing the same for OSPFv2 as well. >>> >>> Thanks, >>> Ketan >>> >>> --Bruno >>> From: [email protected] <[email protected]> >>> Sent: Friday, September 12, 2025 11:15 AM >>> To: [email protected]; DECRAENE Bruno INNOV/NET >>> <[email protected]> >>> Cc: [email protected]; [email protected]; [email protected]; >>> [email protected]; [email protected] >>> Subject: Re: [Lsr] Re: Working Group Adoption Poll for "Updates to Anycast >>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>> Hi Acee, Bruno, >>> We have updated the draft according to your feedback. Please see the diff >>> : >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-anycast-flag-06. >>> Ketan has added the use-cases you were looking for, and we have also made >>> several improvements to the document's overall clarity and organization. >>> We would appreciate it if you could review this latest version. >>> Best regards, >>> Ran (on behalf of the co-authors) >>> Original >>> From: AceeLindem <[email protected]> >>> To: Ketan Talaulikar <[email protected]>; >>> Cc: Bruno Decraene <[email protected]>;lsr <[email protected]>;Dongjie >>> (Jimmy) <[email protected]>;Tony Przygienda >>> <[email protected]>;[email protected] >>> <[email protected]>; >>> Date: 2025幓08ę30ę„ 18:29 >>> Subject: [Lsr] Re: Working Group Adoption Poll for "Updates to Anycast >>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>> Hey Ketan - You still need to respond to this. >>> Thanks, >>> Acee >>> >>>> On Aug 18, 2025, at 9:20āÆAM, Ketan Talaulikar <[email protected]> >>>> wrote: >>>> Hi Acee, >>>> I was away and hence the delay but I've now responded to the IPR poll. >>>> Regarding the update, I don't think I got to it. Please give me some time >>>> to dig into this and get back. Will work with co-authors to update/respond >>>> by next week. >>>> Thanks, >>>> Ketan >>>> On Thu, Aug 14, 2025 at 3:31āÆPM Acee Lindem <[email protected]> wrote: >>>> Hi Ketan, >>>> I still need your response to the WG last call IPR poll. Also, have you >>>> completed your update to the document to address these comments. >>>> Thanks, >>>> Acee >>>> >>>>> On Apr 8, 2024, at 4:59āÆAM, Ketan Talaulikar <[email protected]> >>>>> wrote: >>>>> Hi Bruno, >>>>> Apologies for the delay in response due to my time off. I may be slow in >>>>> response for a couple of weeks more and will need more time to >>>>> update/rework the draft based on the comments received. >>>>> Please check inline below for responses. >>>>> On Fri, Mar 22, 2024 at 7:46āÆPM <[email protected]> wrote: >>>>> Hi Ketan, >>>>> Top posting in effort to also take a step back. >>>>> I could understand the following sematic for the anycast flag: (beware) >>>>> this prefix may be an anycast prefix >>>>> KT> I would say "this prefix IS an anycast prefix" - the operator has >>>>> provisioned it as anycast and so the routers/controllers will consider >>>>> the prefix as anycast. >>>>> In which case, this is an additional indication, itās not mandated for >>>>> any existing behavior, existing behaviors are unchanged and routers needs >>>>> to be equally capable of handling anycast prefix which donāt have this >>>>> AC-flag (just like today). >>>>> Does this align with your objective? >>>>> KT> These "existing behaviors" that you refer to are not specified in >>>>> any RFC and while I am aware of some implementations that do so, we >>>>> should be careful to not assume that these are standards. The objective >>>>> of this document is to simply standardize the Anycast flag that is >>>>> introduced in this document and that this is an indication provisioned by >>>>> the operator. Anything more/further - either related to use-cases or >>>>> "existing behaviors" is outside the scope of this OSPFv2 specific >>>>> document. >>>>> If so, I have the following comments: >>>>> āA prefix that is advertised by a single node and without an AC-flag >>>>> MUST be considered node specific.ā (*2) >>>>> I disagree with this sentence which change the existing behavior and >>>>> does not align with the above semantic. >>>>> For prefix without the AC-flag, one has no new information compared to >>>>> today and the behavior should be unchanged. >>>>> The semantic is AC-flag set Ć anycast prefix (semantic is not: AC-flag >>>>> unset Ć prefix is unicasted) >>>>> KT> Please see my previous comment about anycast behavior. Also, the >>>>> above text has been published as RFC9352/9513 for ISIS and OSPFv3 - so I >>>>> am afraid, but this behavior has been standardized already. OSPFv2 with >>>>> be consistent with the other IGPs in this behavior. >>>>> āBoth SR-MPLS prefix-SID and IPv4 prefix may be configured as >>>>> anycast and as such the same value can be advertised by multiple routers.ā >>>>> Sorry Iām not familiar with OSPF, but ideally the semantic would be the >>>>> same for IS-IS. For IS-IS, multiple L1L2 routers (or ASBR) would >>>>> typically advertise the same prefix when those prefixes are redistributed >>>>> from another area/domain. My reading is that the advertisement of the >>>>> same prefix by multiple ASBR/L1L2 routers does not qualify those prefix >>>>> as anycast. Is that a correct understanding? >>>>> KT> Yes, you are correct. This is not anycast. We can clarify this. >>>>> Regardless, I would welcome a clear definition of āanycastā in the >>>>> context of IGP. (for MPLS, I guess that we could say that a prefix is >>>>> advertised by multiple LERs but Iām not sure there is an equivalent term >>>>> for IGP) >>>>> KT> It is the same IP address that is associated with and therefore >>>>> originated by those nodes. >>>>> Some minor comments: >>>>> āThe AC-Flag MUST be preserved when re-advertising the prefix across >>>>> areas. Ā» >>>>> Ideally also across (IGP) redistribution. (I guess one could say that >>>>> this implementation specific but if we need the AC-flag we also need it >>>>> across domains) >>>>> KT> Agree. >>>>> A priori, removing the term āSR-MPLSā does not change the fact that the >>>>> AC-flag could be set on SR-MPLS SID. So the removal seem mostly >>>>> cosmetic^W editorial to me š >>>>> KT> The flag is set on the prefix and not the SID. It does get >>>>> associated with SID but ultimately it is the property of the prefix and >>>>> not the SID. >>>>> Thanks, >>>>> Ketan >>>>> Thanks >>>>> --Bruno >>>>> From: Ketan Talaulikar <[email protected]> >>>>> Sent: Friday, March 22, 2024 3:30 AM >>>>> To: DECRAENE Bruno INNOV/NET <[email protected]> >>>>> Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; >>>>> [email protected]; Dongjie (Jimmy) >>>>> <[email protected]>; Tony Przygienda <[email protected]> >>>>> Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast >>>>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>>>> Hi Bruno, >>>>> Please check inline below with KT3. >>>>> On Thu, Mar 21, 2024 at 11:28āÆPM <[email protected]> wrote: >>>>> Hi Ketan, >>>>> Please see inline [Bruno2] >>>>> From: Ketan Talaulikar <[email protected]> >>>>> Sent: Thursday, March 21, 2024 4:19 PM >>>>> To: DECRAENE Bruno INNOV/NET <[email protected]> >>>>> Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; >>>>> [email protected]; Dongjie (Jimmy) >>>>> <[email protected]>; Tony Przygienda <[email protected]> >>>>> Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast >>>>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>>>> Hi Bruno, >>>>> Please check inline below with KT2 for responses. >>>>> On Thu, Mar 21, 2024 at 7:16āÆPM <[email protected]> wrote: >>>>> Hi Ketan, >>>>> Thanks for your quick reply. >>>>> Please see inline [Bruno] >>>>> From: Ketan Talaulikar <[email protected]> >>>>> Sent: Thursday, March 21, 2024 2:18 PM >>>>> To: DECRAENE Bruno INNOV/NET <[email protected]> >>>>> Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; >>>>> [email protected]; Dongjie (Jimmy) >>>>> <[email protected]>; Tony Przygienda <[email protected]> >>>>> Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast >>>>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>>>> Hi Bruno, >>>>> Thanks for your feedback. Please check inline below for responses. >>>>> On Thu, Mar 21, 2024 at 4:12āÆPM <[email protected]> wrote: >>>>> Hi all, >>>>> I would also welcome a clear specification of the semantics. >>>>> Such that the meaning and implications are clear on both the originator >>>>> and the receivers/consumers. >>>>> e.g., from the originator standpoint: >>>>> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met >>>>> (which allow for some useful features such asā¦.) >>>>> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met >>>>> (otherwise this breaks ā¦) >>>>> Please specify the CONDITIONS1. >>>>> KT> Whether a prefix is anycast or not is configured by the operator. >>>>> This spec does not require implementations to detect that a prefix that >>>>> it is originating is also being originated from another node and hence >>>>> may be an anycast advertisement. We can clarify the same in the document. >>>>> [Bruno] As an operator, why would I configure this? What for? What are >>>>> the possible drawbacks? (i.e., can this be configured on all prefixes >>>>> regardless of their anycast status) >>>>> KT2> If anycast property is configured on all prefixes, then it is an >>>>> indication that none of those prefixes resolve to a unique node. That has >>>>> consequences in terms of usage. E.g., taking the TI-LFA repair path >>>>> use-case, we won't find the Node SID to be used to form the repair >>>>> segment-list. >>>>> [Bruno2] Given OSPFv2, by SR you mean SR-MPLS I guess. For TI-LFA, if >>>>> you want a Node SID, why not simply picking a SID having the N flag. >>>>> Thatās its semantic. Also with SR-MPLS we donāt do much aggregation so >>>>> Iām not sure to see use for prefix. (by prefix, I mean not a /32 address) >>>>> KT3> Yes, that is why we had the N flag for that specific use case. I >>>>> assume there are no concerns with the use of the N flag and its semantics. >>>>> I would propose those points be discussed in the operation >>>>> considerations section of this draft. >>>>> In the absence of reason, this is not likely be configured IMHO. >>>>> KT2> Sure. Thanks for that feedback. We can certainly do that in the >>>>> draft. I hope this isn't blocking the adoption in your view though, right? >>>>> [Bruno2] I havenāt asked for blocking the adoption. I asked for clearly >>>>> specified semantic. >>>>> e.g., from the receiver standpoint: >>>>> What does this mean to have this Anycast Flag set? What properties are >>>>> being signaled? (a priori this may be already specified by CONDITIONS1 >>>>> above) >>>>> KT> In addition to the previous response, for the receiver this means >>>>> that the same prefix MAY be advertised from more than one node (that may >>>>> be happening now or may happen in the future). This can be clarified as >>>>> well. >>>>> [Bruno] OK. If this is happening now, this is a priori already visible >>>>> in the LSDB. >>>>> KT2> This is tricky. If the prefix is originated in a different domain, >>>>> it gets tricky to determine if the prefix is anycast or dual-homed since >>>>> the LSDB has a local area/domain view. >>>>> [Bruno2] Agreed for prefix. For Node-SID you have the N-flag. Regarding >>>>> origination in another domain, would the ABR/L1L2 node be able to detect >>>>> this and set the anycast flag by itself? >>>>> KT3> It cannot if the case is of anycast originating from different >>>>> domains/areas. >>>>> Any reason to duplicate the info (I would guess thatās easier for >>>>> implementation but since this is not guaranteed to be implemented one >>>>> would need to also check in the LSDB. So doubling the work). >>>>> KT2> This extension brings in simplicity for the receivers provided >>>>> that operators can configure this property. >>>>> [Bruno2] aka moving the complexity to the service provider. I guess you >>>>> would not be surprised if I prefer the other way around (have computer do >>>>> the job instead of humans, have vendors do the job rather than operator >>>>> š) Configuring states and having to maintain/updates them forever is akin >>>>> to a technical debt to me. >>>>> KT3> Here, I think, we may have a point of disagreement. While it is >>>>> outside the scope of this document, I hope we agree that there is a lot >>>>> more involved in the configuration of anycast prefix and the >>>>> service/use-case behind it. The Anycast property config provides a very >>>>> small additional "state" to be provisioned as part of a larger anycast >>>>> service/use-case provisioning. It allows the operator to robustly >>>>> indicate this property of the prefix (they know it is anycast) via the >>>>> IGP without requiring routers and applications to algorithmically figure >>>>> this out (that might not always be correct). I think of it as a useful >>>>> optional lego block in the set of IGP extensions. >>>>> KT2> Like I mentioned above, this starts to get more complicated in >>>>> multi-domain scenarios. Perhaps we can think of this as the complexities >>>>> that we experience in determining this property via an LSDB/topology-db >>>>> that motivate us to bring forth this easier and more robust way. >>>>> Any specific reason requiring the knowledge of the future? >>>>> KT2> Perhaps at time T1, there are two nodes originating the prefix. >>>>> Then at time T2, one of them goes down (or becomes disconnected), do we >>>>> assume that the prefix is now not anycast? Then what happens if that >>>>> other node comes back up again. For certain use-cases where anycast >>>>> prefix is not desired, it may be helpful to completely avoid use of this >>>>> prefix. The operator knows their design and addressing and perhaps is >>>>> able to provision this prefix property correctly from the outset. >>>>> [Bruno2] I guess there could be such use cases. But a priori in the >>>>> general case, when that other node come back 1) before IGP convergence >>>>> nothing change from a routing standpoint, 2) during routing convergence >>>>> you know about this other node and can do what you want. This includes >>>>> updating your FRR protection. If this is really a concerned (to assume >>>>> anycast status while itās not certain) I find a sentence problematic in >>>>> the draft āA prefix that is advertised by a single node and without an >>>>> AC-flag MUST be considered node specific. Ā». TIn fact, the receiver does >>>>> not know whether this is a node specific prefix or an anycast prefix >>>>> advertised by a node not supporting this extension (or an operator not >>>>> doing the right configuration). >>>>> KT3> We have the N and the AC flag. If they are configured properly, >>>>> then there is no ambiguity. But what if they are not? What if there is a >>>>> prefix w/o either of the flags set and say for the use-case like TI-LFA >>>>> we need to use that as a node identifier (because there is nothing else >>>>> from that node). That is the ambiguity that we are trying to cover. Btw, >>>>> that same text is there in RFC9352/9513 and therefore also in this >>>>> document for consistency across the IGPs. >>>>> If this is specific to SR, please say so. >>>>> KT> It is not specific to SR, it is a property of an IP prefix. >>>>> But even in this sub-case, SR anycast has some conditions, both for >>>>> SR-MPLS and SRv6. >>>>> KT> This document does not discuss either SR-MPLS or SRv6 anycast. It >>>>> covers an OSPFv2 extension to simply advertise the anycast property of >>>>> any IP prefix. The discussion of SR anycast belongs to some other >>>>> (SPRING) document ;-) >>>>> [Bruno2] Iām sorry but āSR-MPLSā is the second word in the abstract. So I >>>>> believe this document covers SR-MPLS. IMO anything specific to SR-MPLS >>>>> caused by this document should be covered in this document. >>>>> KT3> That is a mistake that Les has also pointed out. We will fix that. >>>>> SR-MPLS: >>>>> https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1 >>>>> ādetermining the second label is impossible unless A1 and A2 allocated >>>>> the same label value to the same prefix.ā >>>>> āUsing an anycast segment without configuring identical SRGBs on all >>>>> nodes belonging to the same anycast group may lead to misrouting (in >>>>> an MPLS VPN deployment, some traffic may leak between VPNs).ā >>>>> So for SR-MPLS, where we did not have anycast flag at the time, the >>>>> burden of respecting the conditions seems to be on the receiver. In which >>>>> case, Anycast flag didnāt seem to be required. >>>>> KT> True. But that was also beyond the anycast property of the prefix - >>>>> it also involves checking the Prefix SID associated with it (plus other >>>>> considerations) and that is something quite different. >>>>> [Bruno2] Thatās about anycast SR-MPLS SID which is the scope of your >>>>> document. >>>>> KT3> Agree >>>>> SRv6: >>>>> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert >>>>> āAll the nodes advertising the same anycast locator MUST instantiate the >>>>> exact same set of SIDs under that anycast locator. Failure to do so may >>>>> result in traffic being dropped or misrouted.ā >>>>> So for SRv6 the burden is on the originator, and we felt the need to >>>>> define an anycast flag. >>>>> KT> Note that RFC9352 does not restrict the advertisement of anycast >>>>> property of the prefix to SRv6. It applies to all IPv4/IPv6 prefixes - >>>>> irrespective of SRv6, SR-MPLSv4, SR-MPLSv6 or plain old IP. This is the >>>>> same for RFC9513 - since OSPFv3 supports IPv4/IPv6 prefixes as well as >>>>> SRv6, SR-MPLSv4, and SR-MPLSv6. >>>>> [Bruno] Indeed. And note that RFC9352 did specify some specific >>>>> conditions (MUST) before a node may advertise this anycast flag. A priori >>>>> there is a reason for this. A priori the same reason would apply to >>>>> SR-MPLS, no? So why this sentence has not also been copied from RFC9352 >>>>> and adapted for SR-MPLS? (the sentence is āAll the nodes advertising the >>>>> same anycast locator MUST instantiate the exact same set of SIDs under >>>>> that anycast locator. Failure to do so may result in traffic being >>>>> dropped or misrouted.ā) >>>>> KT2> You have a good point. All I can say is that RFC9352/9513 were >>>>> focussed on SRv6 extensions and therefore covered only those aspects. >>>>> This document is not an SR extension and I feel it is better that these >>>>> aspects related to SR anycast (SR-MPLS or SRv6) are covered in a separate >>>>> document in a more holistic manner. >>>>> [Bruno2] On my side, speaking about holistic manner, I would a priori >>>>> have a preference for the document defining the anycast flag to cover the >>>>> anycast properties in an holistic manner. >>>>> KT3> I understand your point of view. My view is that, the way existing >>>>> RFCs stand, we cover only the base protocol semantics of anycast in this >>>>> document and cover the overall SR anycast aspects in a separate (SPRING?) >>>>> document such that it also covers those aspects for ISIS and OSPFv3. >>>>> Interestingly, the conditions seem differentā¦ >>>>> Authors seems to use RFC9352 and RFC9513 as a justification. Iām not >>>>> familiar with OSPFv2 but my understanding is that it does not advertise >>>>> SRv6 SID. So presumably there are some differences >>>>> KT> I hope the previous responses clarify. >>>>> āThe prefix may be configured as anycastā >>>>> Putting the burden on the network operator is not helping clarifying the >>>>> semantic. We need the receivers/consumers and the network operators to >>>>> have the same understanding of the semantic. (not to mention all >>>>> implementations on the receiver side) >>>>> KT> I hope again the previous responses have clarified. >>>>> [Bruno] Not yet. Cf my first point about an operation considerations >>>>> section. >>>>> KT2> Ack for introducing operational considerations. >>>>> So please specify the semantic. >>>>> This may eventually lead to further discussion (e.g., on SR-MPLS) >>>>> KT> That discussion is important and we've had offline conversations >>>>> about that. However, IMHO, that is beyond the scope of this document and >>>>> this thread. >>>>> [Bruno] Too early to tell on my side. >>>>> KT2> How about now? :-) >>>>> [Bruno2] Iād say this discussion in this is in scope of this document. >>>>> Another thread works for me. I picked that thread as I donāt usually read >>>>> OSPF documents but have been convinced by Tony P.ās argument. >>>>> In summary, I understand a bit more the point of view of this document. >>>>> But Iām still concerned that different implementations could have a >>>>> different reaction to this flag. For a link state protocol this seem >>>>> possibly problematic. >>>>> KT3> OK. Let me take a step back. The Anycast property of the prefix >>>>> has been defined for 2 of the 3 IGPs - this document is covering that 3rd >>>>> IGP. As authors, we have already shared the various updates that we have >>>>> agreed to make to the document to clarify the semantics of the anycast >>>>> property of a prefix in OSPFv2. We will continue to incorporate WG inputs >>>>> should the document be adopted. However, as co-author, I do not agree >>>>> that it is in the scope of this document to delve into the use-case (they >>>>> are informative examples and so will be very brief about them in this >>>>> document) and the document should also not delve into the broader SR >>>>> anycast aspects. That later discussion belongs in SPRING. I will leave >>>>> the adoption of the document with that proposed scoping to the WG >>>>> decision. >>>>> Thanks, >>>>> Ketan >>>>> Thanks >>>>> --Bruno >>>>> Thanks, >>>>> Ketan >>>>> Thanks, >>>>> --Bruno >>>>> Thanks, >>>>> Ketan >>>>> Thank you >>>>> --Bruno >>>>> From: Lsr <[email protected]> On Behalf Of Tony Przygienda >>>>> Sent: Wednesday, March 20, 2024 5:44 PM >>>>> To: Acee Lindem <[email protected]> >>>>> Cc: Ketan Talaulikar <[email protected]>; Dongjie (Jimmy) >>>>> <[email protected]>; lsr <[email protected]>; >>>>> [email protected] >>>>> Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast >>>>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>>>> I think the draft is somewhat superfluous and worse, can generate >>>>> completely unclear semantics >>>>> 1) First, seeing the justification I doubt we need that flag. if the >>>>> only need is for the SR controller to know it's anycast since it computes >>>>> some paths this can be done by configuring the prefix on the controller >>>>> itself. It's all centralized anyway. >>>>> 2) OSPF today due to SPF limitations has a "baked-in weird anycast" since >>>>> if prefixes are ECMP (from pont of view of a source) they become anycast, >>>>> otherwise they ain't. I think the anycast SID suffers from same >>>>> limi8ation and is hence not a "real anycast" (if _real anycast_ means >>>>> something that independent of metrics balances on the prefix). Hence this >>>>> draft saying "it's anycast" has completely unclear semantics to me, >>>>> worse, possibly broken ones. What do I do as a router when this flag is >>>>> not around but two instances of the prefix are ECMP to me? What do I do >>>>> on another router when those two instances have anycast but they are not >>>>> ECMP? What will happen if the ECMP is lost due to ABR re-advertising >>>>> where the "flag must be preserved" . >>>>> 3) There is one good use case from my experience and this is to >>>>> differentiate between a prefix moving between routers (mobility) and real >>>>> anycast. That needs however far more stuff in terms of timestamping the >>>>> prefix. pascal wrote and added that very carefully to rift if there is >>>>> desire here to add proper anycast semantics support to the protocol. >>>>> So I'm not in favor in adopting this unless the semantic is clearly >>>>> written out for this flag and the according procedures specified >>>>> (mobility? behavior on lack/presence of flag of normal routers etc). >>>>> Saying " >>>>> It >>>>> is useful for other routers to know that the advertisement is for an >>>>> anycast identifier. >>>>> " is not a use case or justification for adding this. >>>>> if this is "anycast in case of SR computed paths that are not ECMP" >>>>> then the draft needs to say so and call it "SR anycast" or some such >>>>> stuff. If it is something else I'd like to understand the semantics of >>>>> this flag before this is adopted. >>>>> -- tony >>>>> On Wed, Mar 20, 2024 at 5:10āÆPM Acee Lindem <[email protected]> >>>>> wrote: >>>>> Hi Ketan, >>>>> On Mar 20, 2024, at 12:07, Ketan Talaulikar <[email protected]> >>>>> wrote: >>>>> Sure, Acee. We can take that on :-) >>>>> I hope it is ok that this is done post adoption? >>>>> Yup. I realize this is a simple draft to fill an IGP gap but I did ask >>>>> the question below. Hopefully, we can get to WG last call quickly. >>>>> Thanks, >>>>> Acee >>>>> Thanks, >>>>> Ketan >>>>> On Wed, Mar 20, 2024 at 9:35āÆPM Acee Lindem <[email protected]> >>>>> wrote: >>>>> >>>>>> On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar <[email protected]> >>>>>> wrote: >>>>>> Hi Acee/Jie, >>>>>> The most common users of the anycast property of a prefix are external >>>>>> controllers/PCE that perform path computation exercises. As an example, >>>>>> knowing the anycast prefix of a pair of redundant ABRs allows that >>>>>> anycast prefix SID to be in a SRTE path across the ABRs with protection >>>>>> against one of those ABR nodes going down or getting disconnected. There >>>>>> are other use cases. An example of local use on the router by IGPs is to >>>>>> avoid picking anycast SIDs in the repair segment-list prepared for >>>>>> TI-LFA protection - this is because it could cause an undesirable path >>>>>> that may not be aligned during the FRR window and/or post-convergence. >>>>>> That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the >>>>>> burden of this justification of an use-case, I hope the same burden >>>>>> would not fall on this OSPFv2 document simply because it only has this >>>>>> one specific extension. >>>>> But they also weren't added in a draft specifically devoted to the >>>>> Anycast flag. It would be good to list the examples above as potential >>>>> use cases. >>>>> Thanks, >>>>> Acee >>>>> >>>>>> Thanks, >>>>>> Ketan >>>>>> On Wed, Mar 20, 2024 at 8:16āÆPM Acee Lindem <[email protected]> >>>>>> wrote: >>>>>> Hi Jie, >>>>>> I asked this when the flag was added to IS-IS and then to OSPFv3. I >>>>>> agree it would be good to know why knowing a prefix is an Anycast >>>>>> address is "useful" when the whole point is that you use the closest one >>>>>> (or some other criteria). >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>>> On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) <[email protected]> >>>>>>> wrote: >>>>>>> Hi authors, >>>>>>> I just read this document. Maybe I didn't follow the previous >>>>>>> discussion, but it seems in the current version it does not describe >>>>>>> how this newly defined flag would be used by the receiving IGP nodes? >>>>>>> Best regards, >>>>>>> Jie >>>>>>> -----Original Message----- >>>>>>> From: Lsr <[email protected]> On Behalf Of Acee Lindem >>>>>>> Sent: Wednesday, March 20, 2024 4:43 AM >>>>>>> To: lsr <[email protected]> >>>>>>> Cc: [email protected] >>>>>>> Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast >>>>>>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >>>>>>> This starts the Working Group adoption call for >>>>>>> draft-chen-lsr-anycast-flag. This is a simple OSPFv2 maintenance draft >>>>>>> adding an Anycast flag for IPv4 prefixes to align with IS-IS and OSPFv3. >>>>>>> Please send your support or objection to this list before April 6th, >>>>>>> 2024. >>>>>>> Thanks, >>>>>>> Acee >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> ____________________________________________________________________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>>> electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>>> ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or privileged >>>>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender and >>>>> delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have >>>>> been modified, changed or falsified. >>>>> Thank you. >>>>> ____________________________________________________________________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>>> electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>>> ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or privileged >>>>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender and >>>>> delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have >>>>> been modified, changed or falsified. >>>>> Thank you. >>>>> ____________________________________________________________________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>>> electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>>> ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or privileged >>>>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender and >>>>> delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have >>>>> been modified, changed or falsified. >>>>> Thank you. >>>>> ____________________________________________________________________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>>> electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>>> ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or privileged >>>>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender and >>>>> delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have >>>>> been modified, changed or falsified. >>>>> Thank you. >>>> >>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> ____________________________________________________________________________________________________________ >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >>> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >>> modified, changed or falsified. >>> Thank you. >>> _______________________________________________ >>> Lsr 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]
