Hi Shraddha, Thanks for the confirmation. These changes have been already reflected in the latest version.
Thanks, Ketan On Thu, Aug 25, 2022 at 9:19 AM Shraddha Hegde <[email protected]> wrote: > Snipped to open comments. > > > > KT> Since we are talking about SRv6 Locators, that are associated with the > node and not a LAN, I am not sure these fields hold much relevance. Please > let me know if I am missing something. > > <SH> I agree there is no relevance, but its important to specify there is > no relevance and describe what should be filled while sending. > > > > KT2> We don't have these fields in the SRv6 Locator TLV so there is > nothing to be filled in there. I believe you are suggesting clarification > on how these fields need to be filled when an SRv6 Locator is also > advertised as "normal" prefix reachability using the Intra-Area-Prefix TLV > in the E-Intra-Area-Prefix LSA (e.g., for algo 0). Can you please confirm? > > > > <SH2> Yes. That is correct. > > > > > > Juniper Business Use Only > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Monday, August 22, 2022 10:23 AM > *To:* Shraddha Hegde <[email protected]> > *Cc:* Yingzhen Qu <[email protected]>; Acee Lindem (acee) <acee= > [email protected]>; lsr <[email protected]>; > [email protected] > *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for > SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) > > > > *[External Email. Be cautious of content]* > > > > Hi Shraddha, > > > > Thanks for your response. Please check inline below with KT2 for some > clarifications. > > > > We'll work on posting the update once this one remaining discussion point > is closed. > > > > > > On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde <[email protected]> > wrote: > > Hi Ketan, > > > > Pls see inline.. > > > > > > Juniper Business Use Only > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Thursday, August 18, 2022 11:28 PM > *To:* Shraddha Hegde <[email protected]> > *Cc:* Yingzhen Qu <[email protected]>; Acee Lindem (acee) <acee= > [email protected]>; lsr <[email protected]>; > [email protected] > *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for > SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) > > > > *[External Email. Be cautious of content]* > > > > Hi Shraddha, > > > > Thanks for your detailed review and please check inline below for > responses. > > > > > > On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde <[email protected]> > wrote: > > Authors, > > OSPFv3 extensions for Srv6 is a useful draft and I support progressing > this draft. > I have below comments. > > > > 1. Add a section to describe benefits of defining a new locator LSA > rather than > putting locator sub-TLV in existing LSAs. > > > > KT> I do not personally see a significant benefit in using a new LSA as > opposed to re-using existing ones. When this draft was originally proposed, > we (authors) were not able to use the base extended prefix LSAs due to the > mandatory requirement for using the base prefix reachability TLVs per > RFC8362. Hence, we went with the new LSAs so as not to mix up the > reachabilities and follow RFC8362. However, after further discussions in > the WG, there were newer methods determined (e.g., the use of LSInfinity as > a metric for the base prefix reachability TLVs that we are doing for OSPFv3 > IP FlexAlgo). However, by then there were already implementations using the > new LSAs for OSPFv3 SRvt, so it was decided to continue with the approach > of using the new LSAs. > > > > <SH> OK > > > > 2. > "The processing of the prefix > advertised in the SRv6 Locator TLV, the calculation of its > reachability, and the installation in the forwarding plane follows > the OSPFv3 [RFC5340] specifications for the respective route types. > Locators associated with algorithms 0 and 1 SHOULD be advertised > using the respective OSPFv3 Extended LSA types with extended TLVs > [RFC8362] so that routers that do not support SRv6 will install a > forwarding entry for SRv6 traffic matching those locators. When > operating in Extended LSA sparse-mode [RFC8362], these locators > SHOULD be also advertised using the respective legacy OSPFv3 LSAs > [RFC5340]." > > I suggest to change the SHOULD to MUST > and always use legacy LSAs/extended LSAs for reachability > calculation for algo 0 and algo 1. > The current text says use legacy LSAs/extended LSAs if its > there. > > > > KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$> > ). > > > > <SH> If we decide to keep congruent with ISIS, that’s fine > > I noticed that section corresponding to below is missing in OSPF > > “Locators associated with Flexible Algorithms (see Section 4 of > > [I-D.ietf-lsr-flex-algo > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*ref-I-D.ietf-lsr-flex-algo__;Iw!!NEt6yMaO-gk!AgfeMK1a6jfvUWzvxnqwQMEHWncpra4njXu4oVtaPa50UArJK1FjEKrh8U9Hohy8JXxEKDW3IG0CVyojJ1jpMA$>]) > SHOULD NOT be advertised in Prefix > > Reachability TLVs (236 or 237). Advertising the Flexible Algorithm > > locator in regular Prefix Reachability TLV (236 or 237) would make > > the forwarding for it to follow algo 0 path.” > > > > I think this applies to OSPF as well as there is no algo field in the > legacy or > > Extended LSAs. > > > > KT2> Ack. Will include that. > > > > > > > > > > The locator TLV does not seem to have all the information > needed in all cases > for route calculation. From a quick scan I found below info > missing in Locator TLV > > - NSSA forwarding address > > when the locator is exported from another OSPF domain and > originated as a NSSA type > the ability to advertise NSSA fwding address and use it in > route calculation is required > > > > KT> Thanks for catching that. Looks like we've missed the listing of the > IPv6 Forwarding Address and similar sub-TLVs that can be used as a sub-TLV > of the SRv6 Locator TLV. Will fix that and share the update for review. > > <SH>ok > > > > > 3. If authors agree to change as per comment 2 then metric and route-type > fields in locator TLV > for alo 0 and algo 1 must be ignored. > > > > KT> Please see my response to your comment #2. > > > > > 4. Need to add clarification the intra area prefix LSA corresponding to > the locator will have the fields > Referenced LS Type, Referenced Link State ID, and Referenced > Advertising Router > > > > KT> Since we are talking about SRv6 Locators, that are associated with the > node and not a LAN, I am not sure these fields hold much relevance. Please > let me know if I am missing something. > > <SH> I agree there is no relevance, but its important to specify there is > no relevance and describe what should be filled while sending. > > > > KT2> We don't have these fields in the SRv6 Locator TLV so there is > nothing to be filled in there. I believe you are suggesting clarification > on how these fields need to be filled when an SRv6 Locator is also > advertised as "normal" prefix reachability using the Intra-Area-Prefix TLV > in the E-Intra-Area-Prefix LSA (e.g., for algo 0). Can you please confirm? > > > > Thanks, > > Ketan > > > > > > Thanks, > > Ketan > > > > > > Rgds > Shraddha > > > > Juniper Business Use Only > From: Lsr <[email protected]> On Behalf Of Yingzhen Qu > Sent: Wednesday, August 17, 2022 5:22 AM > To: Acee Lindem (acee) <[email protected]> > Cc: lsr <[email protected]>; [email protected] > Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for > SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) > > [External Email. Be cautious of content] > > I support progressing this draft. > > I have the following minor comments for the authors to consider: > > > * The title of Section 4 of this draft is "Advertisement of SRH > Operation Limits", and really it only covers the advertisements of MSDs, so > may consider to change the title to be consistent with the ISIS SRv6 > extensions draft, "Advertising Maximum SRv6 SID Depths". > > * The subsections in section 4 are almost identical to the subsections > in draft-ietf-lsr-isis-srv6-extesions. It's up to the authors and the WG to > decide whether to keep this duplicate. > * In draft-ietf-lsr-isis-srv6-extensions, "topology/algorithm" is > used, and it's not consistently used in this draft. For example, in section > 5 the second paragraph, only "algorithm" is used, while > "topology/algorithm" is used later. > > Nits (line numbers are from idnits): > > 208 the SR Algorithm TLV defined in [RFC8665] as described in > [RFC8666] > SR Algorithm/SR-Algorithm Please add a "-" to be consistent with RFC 8665. > > > 355 The SRv6 Locator LSA has a function code of TBD while the S1/S2 > bits > "TBD" should be replaced with "42" as in IANA considerations. > > Thanks, > Yingzhen > > > On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) <acee= > [email protected]<mailto:[email protected]>> wrote: > > As promised in today's LSR WG meeting, this begins a 3 week WG Last Call, > ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The > extra week is to account for PIST (Post-IETF Stress Syndrome). The > corresponding IS-IS draft is already on the RFC Queue and there are > implementations > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
