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]> On Behalf Of Ketan Talaulikar (ketant) Sent: Monday, September 13, 2021 6:29 PM To: [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-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 [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
