Hi Shraddha, I have not yet received your response to my email below. However, we've gone ahead with the updates as discussed below and it was posted a short while ago: https://mailarchive.ietf.org/arch/msg/lsr/Tv0_jfa05wT1YWd6PG00eFrWXZQ/
Please let us know if there are any further comments pending to be addressed. Thanks, Ketan On Mon, Aug 22, 2022 at 10:22 AM Ketan Talaulikar <[email protected]> wrote: > 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://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#ref-I-D.ietf-lsr-flex-algo>]) >> 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
