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]> 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. > 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. Thanks, Ketan > > > Regards, > > Dirk > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
