Hi Ketan, That is my main point. So we define something which is only local to the area.
If this information will turn out to be very useful I am sure there is going to be someone proposing to leak it :) Remember the UPA discussions ? If so my real question is - should such information belong in IGP ? Or maybe rather in DROID ( https://datatracker.ietf.org/doc/html/draft-li-lsr-droid) ? Honestly I am still a bit struggling to understand the need for it. And the draft is not very helpful ... * The prefix may be configured as anycast and it is useful for other routers to know that the advertisement is for an anycast identifier.* or *2. Use-case In the absence of the N-flag, the node specific prefixes need to be identified from the anycast prefixs. A prefix that is advertised by a single node and without an AC-flag MUST be considered node specific.* Especially the "use-case" looks to me like copy and paste error :) Thx, Robert On Thu, Mar 21, 2024 at 5:44 PM Ketan Talaulikar <[email protected]> wrote: > Hi Robert, > > Summarization/aggregation does result in loss of individual prefixes' > attributes. > > The draft does not intend to specify procedures for propagation of anycast > attribute of individual prefixes to the summary since that is not something > that is going to be robust. > > Thanks, > Ketan > > > On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk <[email protected]> wrote: > >> Hi, >> >> Isn't this knowledge gone outside of the local area when ABR does >> summarization ? If so, is this really practically useful ? >> >> Thx, >> R. >> >> >> On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar <[email protected]> >> wrote: >> >>> 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. >>> >>> >>>> 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? >>> >>> >>>> >>>> >>>> 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. >>> >>> >>>> 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. 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. >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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 ;-) >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> 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. >>> >>> >>>> >>>> >>>> >>>> >>>> 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? :-) >>> >>> 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. >>>> >>>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
