[Idr] Re: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11

[Cheng Li <[e-mail]>]

Hi Sue,

Many thanks for your comments, and sorry for my delay. Please see my reply inline.

Authors, please also see the discussion below. Comments are welcome! Text proposal will be appreciated!

Respect,
Cheng


From: Susan Hares <[e-mail]>
Sent: Sunday, September 1, 2024 5:11 PM
To: [e-mail]
Cc: Cheng Li <[e-mail]>; Lizhenbin <[e-mail]>; [e-mail]; Weiqiang Cheng <[e-mail]>; Ketan Talaulikar <[e-mail]>
Subject: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11

Cheng, Robin, Yuanyang, Weiqiang, and Ketan:

This is a shepherd's review of an IDR SR draft.
Please let me know if you have any questions.

It would help if you would indicate the status of your work.


  1.  Do you have 2 implementations of this draft?

[Cheng]I will call for the implementation report in the mailing list when we update the draft. Thanks!



  1.  Have you finished your technical work on this draft?
[Cheng]I think we have finished.


  1.  Are you ready for WG LC?

[Cheng]yes, but we need two implementation to publish an RFC, correct? Let's see the implementation and decide.



If you would like to update the IDR WG, you may request a time slot at the Sept 9th, 2024 Interim.

Cheerily,
Sue


====================


Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11.

Draft:  draft-ietf-idr-sr-policy-path-segment-11
status: WG draft
Augments: [RFC9012] by allowing new TLVs in Segment list
Status: Needs revision (-12)
Implementation status: Needs 2 implementations

Technical points:

1. Missing RFC9012 context

The abstract, header, and references need to indicate that you are adding TLVs to
Tunnel Encapsulation Attribute for the SR Policy Type.

Abstract change is provided:

Old text:/
   A Segment Routing (SR) policy is a set of candidate SR paths
   consisting of one or more segment lists with necessary path
   attributes.  For each SR path, it may also have its own path
   attributes, and Path Segment is one of them.  A Path Segment is
   defined to identify an SR path, which can be used for performance
   measurement, path correlation, and end-2-end path protection.  Path
   Segment can be also used to correlate two unidirectional SR paths
   into a bidirectional SR path which is required in some scenarios, for
   example, mobile backhaul transport network./

New Text:/
   A Segment Routing(SR) policy identifies a set of candidate SR paths
   Each SR path is passed in BGP as the SR Policy SAFI NLRI
   accompanied with the Tunnel Encapsulation attribute (Tunnel-encaps).  Each
   SR Path (tunnel) uses a set of TLVs in the Tunnel-encaps attribute
   to describe the characteristics of the SR Policy tunnel.  One of the TLVs
   that describes the tunnel is the Segment list TLV which provides a list
   of segments contained in the tunnel.  This document specifies a new
   Path Segment Sub-TLV to associate a Path Segment ID to the SR Segment List.
   The Path Segment ID can be used for performance measurement, path correlation,
   and end-2-end path protection.  This Path Segment identifier can be also
   be used to correlate two unidirectional SR paths into a bidirectional SR path.
   Bidirection SR path may be required in some scenarios such as
   mobile backhaul transport network./

 Hopefully this abstract change will help you make the changes to the
 introduction.  [RFC9012] needs to be included in the references.
[Cheng]Oh my god, why you are so nice? Thank you so much for providing the text! If each reviewer can review the document like you, the progress of each IETF document will be much faster than now. Respect from my bottom of my heart!

Ack, and accept your proposal, thanks!


2. Is there a case when the multiple Path Segment Sub-TLV included in a list
will conflict?  (see section 3.0)
[Cheng] Good question. Till now, I am open with multiple Path Segment TLV, but to simplify the implementation, will recommend to only encode one, and ignore the rest. My proposal is,

__OLD__

Multiple Path Segment MAY be included in a Segment List for different use cases, all of them SHOULD be inserted into the SID List.

__NEW__
Multiple Path Segment MAY be included in a Segment List for different use cases. In SR-MPLS, one, or some or all of them MAY be inserted into the SID List as the requirement of the use case. However, in SRv6, only one Path Segment ID can be encoded in a SRH. Therefore, an implementation MUST decide how to choose a Path Segment ID from the multiple Path Segment IDs. In order to simplify the implementation, this document suggests to encode only one Path Segment sub-TLV for a segment list, while the rest Path Segment sub-TLV SHOULD be ignored.

3. Section 5, error handling,

The operations defined in [I-D.ietf-idr-sr-policy-safi] do not
include your new Sub-TLV.  This document needs to state that:

3-1. Error handling as defined in RFC7606 applies to new Sub-TLVs
as well as SAFI context.

3-2. A BGP Speaker must perform Syntax validation of the new SubTLV
in context.  Must validate
a) length of TLVs and sub-TLVs
b) range of values

If determine malformed, it should "treat-as-withdraw",

3-3. Validation of Tunnel Attribute for valid
a) tunnel
b) sub-TLVs associated with it.

3-4.) Validation SR Candidate routes as active route done by SRPM.

[Cheng]Thanks for your suggestions! I have update it according to your comments.
Please see the diff if you are ok with the update.

4. Security section needs to be added

Please see the security section in SAFI.
The identification of bi-direction and performance segments
adds to the critical nature of some of the information.

[Cheng]added. Please see if it is ok for you.



Editorial changes

NIT-1:  Section 4, paragraph 1, sentence clarity.

old text:/
   In some scenarios, for example, mobile backhaul transport network,
   there are requirements to support bidirectional path. /

New text:/
   In some scenariose such as mobile backhaul transport network,
   there are requirements to support bidirectional path. /

[Cheng]OK.


NIT-2:  Use Sub-TLV consistently in your text

Please use the form "Sub-TLV" consistently.
Change sub-TLV to Sub-TLV.

[Cheng]OK, updated.

If you mean to make difference to the TLVs under Reserve segment, define a term.

[Cheng]we may not like to do so.

NIT-3: Section 4. 1, last paragraph, sentence clarity

Error: Run-on sentence please break this sentence into 2 parts

Current:/
   The Segment sub-TLVs in the Reverse Path Segment List sub-TLV
   provides the information of the reverse SR path, which can be used
   for directing egress BFD peer to use specific path for the reverse
   direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other
   applications./

 New:/
   The Segment sub-TLVs in the Reverse Path Segment List sub-TLV
   provides the information of the reverse SR path. This
   Reverse Path Segment list can be used for directing egress
   BFD peer to use specific path for the reverse
   direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other
   applications./

 [Cheng]Agree! Thanks!