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] > <mailto:[email protected]>> wrote: >> >> >> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar <[email protected] >> > <mailto:[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] >> > <mailto:[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] >> > > <mailto:[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] <mailto:[email protected]>> On Behalf >> > > Of Acee Lindem >> > > Sent: Wednesday, March 20, 2024 4:43 AM >> > > To: lsr <[email protected] <mailto:[email protected]>> >> > > Cc: [email protected] >> > > <mailto:[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] <mailto:[email protected]> >> > > https://www.ietf.org/mailman/listinfo/lsr >> > >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
