Hi Jie, In the terms section, we have listed
SR path: A path described by a segment list [RFC9545]. SRv6 path: A path described by an SRv6 segment list. In section 3, you also can find some explanation. In other words, a SRv6 PSID can be used for a segment list, or multiple segment lists, or all the segment lists in a Candidate path, or part of or all the Candidate path in an SRv6 policy, depending on the need of use cases. Moreover, a segment list may be allocated more than one PSID if needed. For example, the same segment list in different Candidate Path or SR policy can use different PSID. In this way, the traffic in different Candidate Path or SR policy can be differentiated even when they are using the same segment list. Let me add some example here. In [I-D.ietf-idr-sr-policy-path-segment], PCEP [I-D.ietf-pce-sr-path-segment] draft, we define that a Segment list can be identified by a PSID. No need to forbid that different segment list to use a same PSID if a use case need to do so. Therefore, according to the architecture of SR policy, multiple segment lists can be encoded under a Candidate path for ECMP purpose or other purposes. Each segment list under a candidate path can have its own PSID, BUT, we do not need to emphasize that the PSID value HAS TO be different. In normal cases, they should be different. But if we want to merge the statistics of a candidate path, like the total packets number, on the egress node. All the segment lists under this candidate path can use the same PSID. It is easy to understand. Also, we can use different PSID to each segment list, and on the egress node, the node can merge the statistics by merge the data associated with each PSID, this is also doable. In summary, Path segment is used to identify a segment list, which is a SR path. How to allocate the value of a PSID to segment lists is a policy of a use case, it is out of the scope of this document. We just list some explicit use cases in the document for reference. Same in RFC9545. Hope my answer address your comment. Thank you so much for your support! Cheng -----Original Message----- From: Dongjie (Jimmy) <jie.d...@huawei.com> Sent: Friday, September 13, 2024 4:20 AM To: Cheng Li <c...@huawei.com>; spring@ietf.org Cc: draft-ietf-spring-srv6-path-segm...@ietf.org Subject: RE: Request for MORE reviews of draft-ietf-spring-srv6-path-segment-09 Hi Cheng, I've reviewed the latest version of this draft, and think it provides a useful mechanism for SRv6 as RFC 9545 does for SR-MPLS. Thus I support moving it forward. I have one small comment which could be considered either before or as part of the WG LC. In section 3, it says an SRv6 path segment can identify "an SRv6 path or a set of SRv6 path". It is suggested to clarify the scope of the "SRv6 path" here. To my understanding it actually refers to one or multiple SRv6 segment lists of a particular SRv6 policy candidate path. As mentioned in the introduction section, the same segment list may be used by different SRv6 policy candidate paths, and the path segment is used to distinguish the segment list of different candidate paths for performance measurement. Best regards, Jie > -----Original Message----- > From: Cheng Li <c.l=40huawei....@dmarc.ietf.org> > Sent: Monday, September 2, 2024 11:46 PM > To: spring@ietf.org > Cc: draft-ietf-spring-srv6-path-segm...@ietf.org > 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: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Monday, September 2, 2024 5:15 PM > To: i-d-annou...@ietf.org > Cc: spring@ietf.org > 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-segm > ent-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 -- spring@ietf.org To unsubscribe send an email to > spring-le...@ietf.org _______________________________________________ > spring mailing list -- spring@ietf.org To unsubscribe send an email to > spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
