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 <shrad...@juniper.net> wrote:

> Hi Ketan,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar <ketant.i...@gmail.com>
> *Sent:* Thursday, August 18, 2022 11:28 PM
> *To:* Shraddha Hegde <shrad...@juniper.net>
> *Cc:* Yingzhen Qu <yingzhen.i...@gmail.com>; Acee Lindem (acee) <acee=
> 40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org>;
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> *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 <shrad...@juniper.net>
> 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 <lsr-boun...@ietf.org> On Behalf Of Yingzhen Qu
> Sent: Wednesday, August 17, 2022 5:22 AM
> To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>
> Cc: lsr <lsr@ietf.org>; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> 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=
> 40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>> 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to