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 <lsr-boun...@ietf.org> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 12:58 To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; lsr@ietf.org 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Monday, September 13, 2021 6:29 PM To: lsr@ietf.org<mailto:lsr@ietf.org> 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-extensions-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 Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
