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.
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.
              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



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.

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


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.

    
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/__;!!NEt6yMaO-gk!DAXEDn6VRnJtBqXHQdE0K6Smc3xswV5wjsQfMVAtSr2slsMp1MgPE3z27tL8M4RBvnlPen-ceWgz0SvcPXaTjCbD$>


Thanks,
Acee & Chris


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DAXEDn6VRnJtBqXHQdE0K6Smc3xswV5wjsQfMVAtSr2slsMp1MgPE3z27tL8M4RBvnlPen-ceWgz0SvcPTh4ZMqx$>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to