Hi Bruno, Thanks for your responses and clarifications. Please check inline for responses with KT2.
On Thu, Sep 18, 2025 at 9:49 PM <[email protected]> wrote: > Hi Ketan, > > > > Thank for your quick answer. > > Please see inline [Bruno] > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Wednesday, September 17, 2025 2:18 PM > > < 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. > > > > [Bruno] OK. Can this be indicated in the text? > > Note also that the semantic seems very different than the “anycast” > semantic defined in RFCs 9352, 9513, 9402 as the latter defined “anycast” > as functionally equivalent. I fear that having multiple flags with the same > name ‘anycast’ and different semantics may be confusing for the future. > KT2> Yes, we can add that in the text. This document cannot get into other functional aspects as it is only introducing this flag/property and nothing else. > > > > > 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. > > > > [Bruno] Not strictly an answer to your TI-LFA point, but related to > protection RFC 8402 says: > > An Anycast segment or Anycast-SID enforces the ECMP-aware shortest- > > path forwarding towards the closest node of the anycast set. This is > > useful to express macro-engineering policies or protection > > mechanisms. > > > KT2> Ah I see. I read the "protection" part to be more like an egress protection scheme where anycast segments are used for the multihomed PE or such scenarios. > […] > > > > 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#section-3.3 > > > > · 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. > > > > [Bruno] With my current understanding > > - RFCs 9352, 9513, 8402 says: this SID/prefix advertised by multiple > routers is anycast and may be treated as functionally equal. Next > SID/header will have the same meaning on all nodes. > - This document says: this prefix advertised by multiple routers is > anycast and can’t be treated as functionally equal. Next SID/header may > have different meaning on all nodes. > > KT2> Can you please help me with where you are reading that interpretation from this document? Since this document is not introducing any functional properties, it should not be talking about functional equivalence or non-equivalence. > > > > > KT> 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. > > > > [Bruno] If the goal is for the document to specify the OSPFv2 counterpart > of RFCs 9352 and 9513, then I believe the same advertising > conditions/properties needs to apply. > I’m not familiar with OSPFv2 but I’m assuming that this AC flag may be > advertised on a prefix also advertising an SR-MPLS SID. In which case some > person could understand “anycast” as per SR anycast as defined in RFCs > 8402, 9352, 9513. i.e, one case safely use thoe anycast prefix/SID on all > routers advertising it will behave the same way. > KT2> RFCs 9352 and 9513 are about SRv6 and don't apply for OSPFv2 - this is why the AC-flag for prefix was missing on OSPFv2 in the first place and the lead author/editor of this document started this work to 'bridge that gap'. That leaves RFC8402 and since this document is not defining anything for SR-MPLS, I am not sure what further/more can be added. Thanks, Ketan > > > Thanks, > > --Bruno > > > > 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. > > ____________________________________________________________________________________________________________ > 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]
