Hi Acee, Please check inline below.
On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Ketan, > > > > *From: *Lsr <lsr-boun...@ietf.org> on behalf of Ketan Talaulikar < > ketant.i...@gmail.com> > *Date: *Wednesday, August 17, 2022 at 9:48 AM > *To: *Acee Lindem <a...@cisco.com> > *Cc: *lsr <lsr@ietf.org>, "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" > <draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>, "Goethals, Dirk (Nokia > - BE/Antwerp)" <dirk.goeth...@nokia.com> > *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 > > > > 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) <a...@cisco.com> > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
