Hi Dirk, Thanks again for your review and confirmation.
Thanks, Ketan On Mon, Aug 29, 2022 at 4:31 PM Goethals, Dirk (Nokia - BE/Antwerp) < dirk.goeth...@nokia.com> wrote: > Hi Ketan, > > The update looks good to me. > > Thx, > > Dirk > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Ketan Talaulikar > *Sent:* Tuesday, August 23, 2022 8:02 PM > *To:* Acee Lindem (acee) <a...@cisco.com> > *Cc:* lsr <lsr@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) > > > > Hi Acee/Dirk, > > > > The updated version posted earlier today addresses Dirk's comments and was > announced to the LSR WG list: > https://mailarchive.ietf.org/arch/msg/lsr/Tv0_jfa05wT1YWd6PG00eFrWXZQ/ > > > > Please let me know if there are any further changes/updates pending. > > > > Thanks, > > Ketan > > > > > > On Wed, Aug 17, 2022 at 9:08 PM Acee Lindem (acee) <a...@cisco.com> wrote: > > Hi Ketan, > > > > *From: *Ketan Talaulikar <ketant.i...@gmail.com> > *Date: *Wednesday, August 17, 2022 at 11:35 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) > > > > 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. > > > > I think we’re agreeing, I’ve seen the same use case presentations and it > is, IMO, a far better usage than prefix unreachability 😉 > > > > Thanks, > > Acee > > > > Thanks, > > Ketan > > > > > > On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee) <a...@cisco.com> wrote: > > Hi Ketan, > > > > *From: *Ketan Talaulikar <ketant.i...@gmail.com> > *Date: *Wednesday, August 17, 2022 at 11:04 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) > > > > 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 > > > > > > 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) <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
