[spring] Re: Request for MORE reviews of draft-ietf-spring-srv6-path-segment-09

["[e-mail]" <[e-mail]>]

Hi, Cheng:

1) I think adding this text would be helpful for understanding.
2) Yeah, I think path segment may have more interesting use cases when considering intermediate nodes, which can be further explored in future discussions.

Best,
Zehua
 
From: Cheng Li
Date: 2024-09-06 00:00
To: [e-mail]
CC: SPRING WG List
Subject: RE: [spring] Request for MORE reviews of draft-ietf-spring-srv6-path-segment-09
Hi Zehua,
 
Thanks for your comments! Please see my reply inline.
 
BR,
Cheng
 
From: [e-mail] <[e-mail]> 
Sent: Thursday, September 5, 2024 3:10 PM
To: Cheng Li <[e-mail]>
Cc: SPRING WG List <[e-mail]>
Subject: Re: [spring] Request for MORE reviews of draft-ietf-spring-srv6-path-segment-09
 
Hi, Cheng:
 
Thanks for the draft. Just 2 questions here.
 
4.1. SRH.P-flag
-In some use cases, only the egress needs to process the SRv6 Path Segment, therefore, the P-flag processing can be done at the egress node only while the intermediate nodes do not need to process it.
1) I think this paragraph and the following pseudo code indicate that the intermediate node can also process path segment. The use case listed in the manuscript are focused on end-to-end scenarios, it might help understand if there are more description about the scenarios related intermediate nodes.
 
[Cheng]How about adding some text below the pseudo code? Like
 
When the SRH.P-flag is set, the Path Segment processing is enabled. In the cases that the intermediate processing of Path Segment is disabled, a node will process the Path Segment only when it is the last segment endpoint node indicating by SL == 0. In this case, when the nodes are an intermediate node, it will ignore the Path Segment. When the intermediate processing is enabled, all the segment endpoint nodes along the path are able to process the Path Segment if a Path Segment is encoded in the SRH.  There are some use cases that metadata of the packets will be collected and processed on the intermediate nodes, especially for the stateful use cases. The details of these use cases are out of the scope of this document, and will be described in other documents in the future. 
 
 
2) In this situation, should introduce parameters or adjust the P-flag processing to specify which intermediate node needs to process the path segment, rather than having all intermediate nodes process it?
[Cheng] IMHO, that is depends on specific use case. In this draft, let’s make it simple. You are welcome to propose a new draft to define this, if you have interests on this 
 
Thank you for your comments!
 
 
Best,
Zehua
China Telecom
 
 
From: 【外部账号】Cheng Li
Date: 2024-09-02 23:45
To: [e-mail]
CC: [e-mail]
Subject: [spring] Request for MORE reviews of draft-ietf-spring-srv6-path-segment-09
Hi SPRING,
 
The SR-MPLS Path Segment draft has been published as RFC9545, and we think the content of SRv6 Path Segment draft is quite stable and mature, so we hope to see more tech reviews on it so that we can move the draft forward.
 
The draft is quite simple and straightforward, and it defines a new type of segment called Path Segment, which is useful to identify an SRv6 path, similar to SR-MPLS path segment. 
The draft only defines the location that the SRv6 Path Segment should appear, the possible general formats of it, and the general handling of Path Segment. How to allocate the value to a Path Segment is out of the scope of this draft and should be defined as per use cases.
An SRv6 Path Segment will not be used for routing so it should not be copied to the IPv6 destination address.
 
Many thanks for Adrian, Stefano and Zafar for their useful comments and help on this draft. More reviews and comments are welcome!
 
Thanks,
Cheng
 
 
 
-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Monday, September 2, 2024 5:15 PM
To: [e-mail]
Cc: [e-mail]
Subject: [spring] I-D Action: draft-ietf-spring-srv6-path-segment-09.txt
 
Internet-Draft draft-ietf-spring-srv6-path-segment-09.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF.
 
   Title:   Path Segment for SRv6 (Segment Routing in IPv6)
   Authors: Cheng Li
            Weiqiang Cheng
            Mach(Guoyi) Chen
            Dhruv Dhody
            Yongqing Zhu
   Name:    draft-ietf-spring-srv6-path-segment-09.txt
   Pages:   13
   Dates:   2024-09-02
 
Abstract:
 
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding an ordered list of instructions, called "segments".
   The SR architecture can be implemented over an MPLS data plane as
   well as an IPv6 data plane.
 
   Currently, Path Segment has been defined to identify an SR path in
   SR-MPLS networks, and is used for various use-cases such as end-to-
   end SR Path Protection and Performance Measurement (PM) of an SR
   path.  This document defines the Path Segment to identify an SRv6
   path in an IPv6 network.
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/
 
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-09
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-path-segment-09
 
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
 
 
_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]