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,

One quick response inline below with KT.


On Thu, Mar 21, 2024 at 10:37 PM Robert Raszuk <[e-mail]> wrote:

> 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 ?
>

KT> Prefixes do get re-advertised (in OSPF we don't "leak" ;-)) across
areas without necessarily being summarized. As mentioned, there is no
discussion about summarization in this spec.

Thanks,
Ketan


>
> 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 <[e-mail]>
> 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 <[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
>>>>
>>>