Hi Peter, You're correct w.r.t. E-Intra-Area-Prefix-LSA It's different for E-Inter-Area-Prefix-LSA.
As mentioned, rfc8362 explicitly says below: "If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, it is treated as malformed as described in Section 5." So an E-Inter-Area-Prefix-LSA without an E-Inter-Area-Prefix-LSA is considered malformed and rejected by our implementation. As a result, our implementation always add an Inter-Area-Prefix TLV when advertising a "OSPFv3 Extended Prefix Range TLV" in a E-Inter-Area-Prefix-LSA. The Inter-Area-Prefix TLV is filled with all zero's, and the NU-bit is set so that it gets ignored. Maybe, we can do same for this SRv6 locator. Regards, Dirk -----Original Message----- From: Peter Psenak <[email protected]> Sent: Tuesday, September 14, 2021 11:52 AM To: Ketan Talaulikar (ketant) <[email protected]>; Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]>; [email protected] Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote: > Hi Dirk, > > Your point is related to my original concern/interpretation for why we > introduced a new LSA type for SRv6 Locator than use the existing > Extended Prefix LSA types. This goes back to the original intention of > the WG and authors of RFC8362. > > If one can never generate the E-*-Prefix LSAs (e.g. > E-Inter-Area-Prefix-LSA) without the presence/inclusion of their > corresponding “base” prefix-reachability TLVs (e.g. Inter-Area-Prefix > TLV), then these extended LSAs cannot be used for advertisement of > SRv6 Locators in OSPFv3. This is because, for FlexAlgo we need the > ability to advertise only the SRv6 Locators without the “base” prefix > reachability. > > I was made to understand, however, that the text in RFC8362 was only > in the context of base OSPFv3 SPF and it was not intended to make the > “base” prefix reachability TLVs mandatory in the extended LSAs. Hence > the proposal for this change. > > Would like to know the WG and RFC8362 authors views on this aspect. > > Regd the NU bit, that applies for when Prefix SID mapping for an > individual prefix is advertised by the SRMS by using the Prefix-SID > sub-TLV inside the Intra/Inter/External Prefix TLVs. I was talking > about the advertisement of ranges using the OSPFv3 Extended Prefix > Range TLVs – there is no NU bit in the picture here AFAIK. I am > referring to the text in > https://datatracker.ietf.org/doc/html/rfc8666#section-8.1 > > Are you saying that implementations today are advertising say > Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended > Prefix Range TLV in the same E-Intra-Area-Prefix LSA for advertisement > of SRMS ranges? If so, this was not very clear to me from RFC8666. I see no reason to send Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV. The text in rfc8666 says "An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs when advertising SIDs for prefixes.". That should be sufficient. thanks, Peter > > Thanks, > > Ketan > > *From:*Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]> > *Sent:* 14 September 2021 14:15 > *To:* Ketan Talaulikar (ketant) <[email protected]>; Ketan Talaulikar > (ketant) <[email protected]>; [email protected] > *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding > > Hi Ketan, > > I’m not sure I understand your reply correctly. > > The same paragraph also mentions: > > If the Inter-Area-Prefix TLV is not included in the > E-Inter-Area-Prefix-LSA, > > it is treated as malformed as described in Section 5 > <https://datatracker.ietf.org/doc/html/rfc8362#section-5>. > > w.r.t OSPFv3 Extended Prefix Range TLV > > I’ve been told that the NU-bit > (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1) > > is used to exclude it from unicast. > > I’m I missing something? > > Thx, > > Dirk > > *From:*Ketan Talaulikar (ketant) <[email protected] > <mailto:[email protected]>> > *Sent:* Tuesday, September 14, 2021 9:56 AM > *To:* Goethals, Dirk (Nokia - BE/Antwerp) <[email protected] > <mailto:[email protected]>>; Ketan Talaulikar (ketant) > <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding > > Hi Dirk, > > There was a misunderstanding of Acee's comment and its context on my > part. More specifically my misunderstanding on what RFC8362 text > intended to say. > > E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says > the following > > In order to retain > > compatibility and semantics with the current OSPFv3 specification, > > each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix > > TLV. > > I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 > E-Inter-Area-Prefix LSA and other TLVs may be added optionally. > However, this does not seem to be the correct interpretation since we > already have introduced the OSPFv3 Extended Prefix Range TLV in > https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a > top-level TLV and may be used for a prefix without its corresponding > Inter-Area-Prefix TLV. > > So we can introduce the SRv6 Locator TLV similar to the Prefix Range > TLV into the existing Prefix LSAs as indicated by Acee and there would > not be an issue. > > Thanks, > > Ketan > > -----Original Message----- > From: Lsr <[email protected] <mailto:[email protected]>> On > Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) > Sent: 14 September 2021 12:58 > To: Ketan Talaulikar (ketant) <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding > > Hi Ketan, > > I'm not against this suggested change. > > I noticed however, that Acee suggested this a while back and at that > time you mentioned an issue when flex-algo locators where advertised > this way, see snip below. Can you elaborate on why this is no longer > an issue? > > Thx, > > Dirk > > <snip> > > [Acee] > > Why do you define a separate SRv6 Locator LSA to advertise SRv6 > reachability? One of the primary benefits of RFC8362 is to advertise > all the information associated with a prefix in one LSA. Now you have > negated that benefit by putting this information in a separate LSA. > > [KT] We need to define a new LSA since this is not an extension for > the normal prefix reachability. For doing FlexAlgo with SRv6, the > locators are used for reachability computation within the FlexAlgo. If > these were advertised as normal prefix reachability then routers which > are not part of the FlexAlgo or even routers not supporting SRv6 would > program them. > We've tried to explain this in > https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5. > > -----Original Message----- > > From: Lsr <[email protected] <mailto:[email protected]>> On > Behalf Of Ketan Talaulikar (ketant) > > Sent: Monday, September 13, 2021 6:29 PM > > To: [email protected] <mailto:[email protected]> > > Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding > > Hello All, > > Some feedback has been received with suggestions to change the > encoding currently proposed in the draft - more specifically related > to > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-exten > sions-02#section-6 > > The proposal is to do away with the need for introduction of a new LSA > for SRv6 Locator and instead advertise the SRv6 Locator as a new > top-level TLV within all the extended Prefix LSAs introduced in RFC8362. > The advantage is simpler processing for the scenarios where the prefix > is advertised as both a normal prefix reachability as well as SRv6 > Locator. It also results in avoiding the handling of a new LSA type in > OSPFv3. > > I would like to poll the WG to check if there are any existing > implementations of the draft in the current form (even though > codepoints have not yet been allocated). Also, if there is any > objection to introducing this change. > > Thanks, > > Ketan > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
