Hi Ketan, See my responses inline. Dirk From: Ketan Talaulikar <[email protected]> Sent: Thursday, August 11, 2022 4:15 PM To: Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Comments on draft-ietf-lsr-ospfv3-srv6-extensions
Hi Dirk, Thanks for your review and please check inline below for my responses. On Thu, Aug 11, 2022 at 7:10 PM Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]<mailto:[email protected]>> wrote: Hi authors, I’ve read draft-ietf-lsr-ospfv3-srv6-extensions-06, and have one comment. In chapter “6.1. SRv6 Locator TLV” you mention the A-flag, with info similar to what is mentioned in ISIS. [draft-ietf-lsr-isis-srv6-extensions] I’m missing the consistency with the other SR drafts for OSPF: 1) We don’t have the A-flag In OSPFv3 SR-MPLS. Either the N-bit [rfc8362] is set and then the advertised SID is a Node-sid, or it is not set then the advertised SID is an any-cast SID. KT> You are correct. There is an individual draft that is trying to bring in this Anycast Flag for normal prefix reachabilities in both OSPFv2 and v3: https://datatracker.ietf.org/doc/html/draft-chen-lsr-anycast-flag-01 ... this draft is introducing the Anycast flag only for SRv6 Locators. [DG>] OK 2) On the other hand, we do have an A-flag (attached flag) in OSPFv2 [RFC7684] to indicated that the advertised SID is local to the ABR/ASBR node but yet in other area/AS. Similar the LA-bit is used in OSPFv3. [rfc8362] KT> Ack. That is not the Anycast flag. IMHO, this “attached flag” is missing in this draft unless we modify the definition of the mentioned A-flag in this draft. KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation of SRMS advertisements. The question is if that is required or relevant for SRv6 Locators. There is no harm/issue with introducing a new Attached flag (even if I am not sure of its use) and renaming the current Anycast flag to something else (e.g., AC?). But perhaps I might be missing something and if so, please clarify. [DG>] I was referring to the text mentioned in RFC8362 chapter 3.1 Prefix Options Extensions, for the reasons as mentioned in yellow below. As such, it would be equally useful for the ABR’s local ‘node-locators’, unless the ABR is advertising these local ‘node-locators’ in all area’s as route-type 1, is that the plan? The prefix options are extended from Appendix A.4.1.1<https://datatracker.ietf.org/doc/html/RFC8362#appendix-A.4.1.1> [OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>]. The applicability of the LA-bit is expanded and it SHOULD be set in Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when the advertised host IPv6 address, i.e., PrefixLength = 128, is an interface address. In RFC 5340<https://datatracker.ietf.org/doc/html/rfc5340>, the LA-bit is only set in Intra- Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>]). This will allow a stable address to be advertised without having to configure a separate loopback address in every OSPFv3 area. Thanks, Ketan Regards, Dirk
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
