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<mailto:a...@cisco.com>> wrote: Hi Ketan, From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Date: Wednesday, August 17, 2022 at 9:48 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>> Cc: lsr <lsr@ietf.org<mailto:lsr@ietf.org>>, "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>" <draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>, "Goethals, Dirk (Nokia - BE/Antwerp)" <dirk.goeth...@nokia.com<mailto: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<mailto: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
