Hi Cheng, Thank you for your expedient response. I need to find more reason for the definition of SRv6 Path Segment because, as I understand it, SRH, by its nature, provides sufficient identification of the segment list traversed by the particular SR Policy. And that is fundamentally different from the SR-MPLS scenario. Could you please elaborate on why the endpoint of the SR Policy requires SRv6 PSID while all the needed information is readily available within SRH?
Regards, Greg On Fri, Sep 6, 2024 at 10:25 AM Cheng Li <c...@huawei.com> wrote: > Hello Mirsky, > > > > Long time no see, hope you are doing great! > > > > Well, I agree with you that we can use STAMP and other active OAM methods, > this is obviously. > > This document defines the SRv6 Path Segment which is similar to SR-MPLS > Path Segment, even regarding this point, they can be used in the same way > in SR policies: > > > > 1) A PSID can be used for one(normal use case), or more segment > lists, for aggregation. > > 2) A segment list can have more than one PSID, in a same SR policy or > different Policy. (Become different SR policy are independent, and they > need their own statistics) > > > > The only key point is that the egress node knows the mapping between PSID > and segment list. Whether it is used in 1:1, 1:N or N:1, is totally > depends on the use case, and this is simple math, we provide the mechanism, > and do not block operators to do anything as long as no bugs. > > > > Also, some logic has been described in RFC9545. > > > > A PSID is used to identify a segment list. However, one PSID can be > > used to identify multiple segment lists in some use cases if needed. > > For example, one single PSID MAY be used to identify some or all > > segment lists in a candidate path or an SR policy if an operator > > would like to aggregate these segment lists in operation. > > > > Thank you for your comments 😊 > > > > Respect, > > Cheng > > > > > > > > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* Friday, September 6, 2024 5:37 PM > *To:* Cheng Li <c...@huawei.com> > *Cc:* Joel Halpern <j...@joelhalpern.com>; LiJie Deng < > denglijie1...@gmail.com>; spring@ietf.org > *Subject:* Re: [spring] Re: spring Digest, Vol 129, Issue 43 > > > > Hi Cheng, > > I think that there some information about the per SR Policy performance > measurement is not clear to me. AFAIK, performance measurement methods > support concurrent test sessions over the same path between the particular > set (p2p or p2mp) of systems. For example, in STAMP one can use Stamp > Session Identifier (SSID). Thus, I don't see any benefit of using data > plane information for demultiplexing OAM sessions. I appreciate your > thoughts on this. > > > > Regards, > > Greg > > > > On Fri, Sep 6, 2024 at 5:28 AM Cheng Li <c.l=40huawei....@dmarc.ietf.org> > wrote: > > Hi Joel, > > > > Thank you for your email. > > We might think about two type of cases here. > > > > 1. A segment list use a single PSID(Segment list: PSID is 1:1): this > is a normal case, can be covered by other text in the draft, no special > text is needed. All the SR Policy use the same PSID for a specific segment > list. Then we will get an aggregated statistics on the egress node. That is > simple. > > 2. A segment list can have multiple different value PSIDs(Segment > list: PSID is 1:N). This design allows the operators to separate the > statistics for separate subsets of traffic over a path. This is an > object-oriented design, each SR policy has its own candidate path, own > segment list, own path. Though the segment list may be the same with other > ones in other SR policies, but a SR policy do not care about others, but > only see its own segment list identified by a path segment. But in any > case, we do not force people to do so, this draft only provide the > capability to use different value of PSID for a segment list. In other > worlds, each SR policy has its own path with its PSID, and different SR > policy’s path(with different PSID) might reuse the same segment list. In > my point of view, it is the PSID. > > We might add some text to explain more? You comment or text proposal will > be very welcome! > > > > Thanks, > > Cheng > > > > > > > > *From:* Joel Halpern <j...@joelhalpern.com> > *Sent:* Thursday, September 5, 2024 7:18 PM > *To:* Cheng Li <c...@huawei.com>; LiJie Deng <denglijie1...@gmail.com>; > spring@ietf.org > *Subject:* Re: [spring] Re: spring Digest, Vol 129, Issue 43 > > > > I can understand why the operator may want separate statistics for > separate subsets of traffic over a path. But then the ID being used does > not seem to be a path ID. It identifies something, but I am not sure > what. If it identified just the path, then all the packets for all > applications using the same path would be required to have the same ID, > which you are explicitly saying is not the case. > > Yours, > > Joel > > On 9/5/2024 11:44 AM, Cheng Li wrote: > > Hi Lijie, > > > > Yes, it is common for operators to carry multiple services with different > policies over links. > > > > That text is for the use cases that an operator would like to measure the > packets for the paths(identified by its segment list) within its Policy. > But on the egress node, the node will get the aggregated statistics of > packets since different services may reuse the same segment list/path. > > > > In the cases that operator would like to measure the paths in different > policies/services, same segment list/path in a specific policy should be > identified, and differentiated with the same segment list in other > policies. By using different Path Segment ID, same segment List/path can be > differentiated, so that the traffic can be measured alone. Otherwise, only > the aggregated result will be produced on the egress node. > > > > Hope I make it clear. Thank you for your comment. We may need to add some > text in this section? You are welcome to share your proposal. > > > > Thanks, > > Cheng > > > > > > > > > > > > *From:* LiJie Deng <denglijie1...@gmail.com> <denglijie1...@gmail.com> > *Sent:* Thursday, September 5, 2024 11:08 AM > *To:* spring@ietf.org > *Subject:* [spring] Re: spring Digest, Vol 129, Issue 43 > > > > Hi Cheng, > > I have a question about the draft. > > There is this sentence in the "introduction" section: "Furthermore, > different SRv6 policies may use the same segment list for different > candidate paths, so the traffic of different SRv6 policies are merged, > resulting in the inability to measure the performance of the specific path." > > *-* I don’t see the issue with "merged traffic of different SRv6 > policies", and how it relates to "the inability to measure the performance > of the specific path". For operators, it’s very common to carry multiple > services with different policies over links. In addition, there are many > methods to measure service performance, such as IOAM. > > BR, > > Lijie > > > > _______________________________________________ > > 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
