Hi Acee, The routing for anycast is transparent but there are features and use cases where the knowledge of Anycast is required or helpful. I don't have all the draft pointers, but there have been presentations in SPRING and RTGWG WGs on redundancy and protection features that leverage anycast.
Thanks, Ketan On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee) <[email protected]> wrote: > Hi Ketan, > > > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Wednesday, August 17, 2022 at 11:04 AM > *To: *Acee Lindem <[email protected]> > *Cc: *lsr <[email protected]>, "[email protected]" > <[email protected]>, "Goethals, Dirk (Nokia > - BE/Antwerp)" <[email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for > SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) > > > > Hi Acee, > > > > Please check inline below. > > > > > > On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) <[email protected]> wrote: > > Hi Ketan, > > > > *From: *Lsr <[email protected]> on behalf of Ketan Talaulikar < > [email protected]> > *Date: *Wednesday, August 17, 2022 at 9:48 AM > *To: *Acee Lindem <[email protected]> > *Cc: *lsr <[email protected]>, "[email protected]" > <[email protected]>, "Goethals, Dirk (Nokia > - BE/Antwerp)" <[email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for > SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) > > > > Hello Acee/All, > > > > There has not been any further comment/feedback on the point that Dirk > brought up in the thread below: > > https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/ > > > > I want to point out that not just the LA-flag, but also the P-flag is > required for propagation of the SRv6 Locator LSA across NSSA. > > > > Perhaps the best option available to us is to replace the "Flags" field in > the SRv6 Locator TLV (refer to > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-06#section-6.1) > with the "PrefixOptions" field that is present in all the OSPFv3 prefix > reachability advertisements in RFC5340/8362. This will also bring a nice > consistency for OSPFv3 even though some flags are unused in the SRv6 > context. > > > > We only have 1 bit left - > https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4 > So, perhaps we need to add the PrefixOptions using the existing registry > and we need a new field and registry that could be advertised in Extended > LSAs. > > > > KT> This is the idea behind > https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ - > hopefully, we can bring it up for WG adoption soon. I believe Anycast is a > strong enough use case to consume the remaining unused bit and the > introduction of a new extensible Flags sub-TLV should take care of future > extensions as proposed in the aforementioned individual draft. > > > > Is this the first introduction of the N flag for OSPFv3 in any LSA? I > don’t see it in https://datatracker.ietf.org/doc/rfc8666/ > > > > KT> N flag in PrefixOptions came via RFC8362 and so RFC8666 didn't have to > do anything about it. Refer > https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4 > > > > > > Ok – I thought I remembered the N-Flag but I didn’t look close enough at > the existing IANA assignments. I agree we can use the add the Anycast Bit > to the Prefix Options. Although it seems to negate the fact that anycast > can be routed transparently, there are enough drafts presenting use cases > as to why it is needed. > > > > Thanks, > Acee > > > > > > > > Additionally, we can use the remaining bit available for AC-flag (anycast) > similar to the ISIS SRv6 spec. > > > > Note that this change would not be backward compatible with the current > spec since the bit positions are moving. > > > > Looking for feedback/input from the WG on this proposed change. > > > > I think we’d just need to get feedback from Dirk (who made the comment > that initiated this) and the co-authors. Of course, anyone with know of > OSPFv3 SRv6 can comment. > > > > KT> I did discuss offline with Dirk and we agreed on the necessity for the > LA and P flags for OSPFv3 SRv6. We have not discussed the approach of using > PrefixOptions instead of the Flags field though and Dirk is now on PTO. I > hope others can share their views on the PrefixOptions approach. > > > > Thanks, > > Ketan > > > > > > Thanks, > Acee > > > > Thanks, > > Ketan > > > > > > On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) <[email protected]> > wrote: > > As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, > ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The > extra week is to account for PIST (Post-IETF Stress Syndrome). The > corresponding IS-IS draft is already on the RFC Queue and there are > implementations. > > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ > > > > > > Thanks, > > Acee & Chris > > > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
