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. 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]
