Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
>> Hi Bruno,
>>
>> Please check inline below with KT2 for responses.
>>
>>
>> On Thu, Mar 21, 2024 at 7:16 PM <[e-mail]> wrote:
>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> Thanks for your quick reply.
>>>
>>> Please see inline [Bruno]
>>>
>>>
>>>
>>> *From:* Ketan Talaulikar <[e-mail]>
>>> *Sent:* Thursday, March 21, 2024 2:18 PM
>>> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
>>> *Cc:* Acee Lindem <[e-mail]>; lsr <[e-mail]>;
>>> [e-mail]; Dongjie (Jimmy) <
>>> [e-mail]>; Tony Przygienda <[e-mail]>
>>> *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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Tony Przygienda
>>> *Sent:* Wednesday, March 20, 2024 5:44 PM
>>> *To:* Acee Lindem <[e-mail]>
>>> *Cc:* Ketan Talaulikar <[e-mail]>; Dongjie (Jimmy) <
>>> [e-mail]>; lsr <[e-mail]>;
>>> [e-mail]
>>> *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 <[e-mail]> wrote:
>>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> On Mar 20, 2024, at 12:07, Ketan Talaulikar <[e-mail]>
>>> 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 <[e-mail]> wrote:
>>>
>>>
>>>
>>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar <[e-mail]>
>>> 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 <[e-mail]>
>>> 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) <[e-mail]>
>>> 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 <[e-mail]> On Behalf Of Acee Lindem
>>> > > Sent: Wednesday, March 20, 2024 4:43 AM
>>> > > To: lsr <[e-mail]>
>>> > > Cc: [e-mail]
>>> > > 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
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/lsr
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>