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

[[e-mail]]

+1 to Robert’s points.

Also, authors state that this is the same thing that RC9513 and RFC9352, while draft-chen-lsr-anycast-flag specification is different. The difference being : 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.
The difference seems significant in term of enforcement (MUST) and consequences (traffic being dropped or misrouted)

So is this the same semantic or not? If so, why a different specification? If not, using the same name for different things is usually unwise.


Is “anycast” prefix the same as “multi-homed prefixes (MHPs)” as per RFC851? If not please specify the differences. If so, why using a different name?

My understanding is that a loopback from a node in ISIS L1 (1) and readvertised in L2 by multiple L1L2 routers would not be qualified as an anycast prefix although ‘”the same prefix [is] advertised by multiple routers”. If so “the same prefix advertised by multiple routers” is not the correct semantic for “anycast”. So what it the correct one?

If L1L2 routers do aggregation, it’s not clear to me whether the aggregate should be qualified as anycast of not.

Finally, if the semantic is obvious to authors, a simple resolution is to write this down in the specification. If it’s not, the problematic should be obvious (at least it’s unlikely that all operators in the world would agree on the semantic, which problematic is it’s up to them the configure this)

Thanks,
Bruno


  1.  I know the draft is about OSPF but presumably the “anycast” semantic is not dependent on the protocol

From: Lsr <[e-mail]> On Behalf Of Robert Raszuk
Sent: Saturday, March 23, 2024 10:55 PM
To: Acee Lindem <[e-mail]>
Cc: 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

Hi Acee and WG,

> Those questioning the flag should have been paying attention
> when RFC 9513 and RFC 9352 were being discussed.

No.

#1 Those two RFCs are about segment routing extensions. draft-chen-lsr-anycast-flag is not.

#2 In those two RFCs it is very clear that anycast flag reflects only the local configuration of the prefix (locator). Please observe that the draft under discussion fails to indicate who and when should set this flag. Quoted RFCs do. Number of questions surfaced if ABRs or ASBRs should be setting such flag. Should summaries have such flag ? Etc ....

#3 In those two RFCs there is very good justification why this flag can be useful .. to check if anycast prefixes are advertised with the same SIDs. To me this is sufficient justification and perhaps a good reason why no one had objections to RFC9513 and RFC9352.

Neither #1, nor #2 nor #3 apply to the subject draft for OSPFv2. While #2 hopefully can be easily added #1 and #3 are fundamentally different. So at least draft-chen-lsr-anycast-flag should provide a justification being as good as #3.

So justification to add it here just because OSPFv3 or ISIS have it is not enough.

Kind regards,
Robert


On Sat, Mar 23, 2024 at 10:38 PM Acee Lindem <[e-mail]<mailto:[e-mail]>> wrote:
Speaking as WG member:

I support working group adoption.

It would be good to add:

   1. In the introduction, informational references to OSPFv3 [RFC9513] and ISIS [9352].
   2. The example use cases for the prefix Anycast flag we've been discussing.

Note that we already have this flag for OSPFv3 and IS-IS and implementations are making use of it. That ship has left the dock
and now is the time to question whether the use cases could be solved in a different manner. Those questioning the flag should
have been paying attention when RFC 9513 and RFC 9352 were being discussed.

Thanks,
Acee



> On Mar 19, 2024, at 2:43 PM, Acee Lindem <[e-mail]<mailto:[e-mail]>> wrote:
>
>
> 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]<mailto:[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.