Speaking as a participant, it seems that at least a clear explanation of
what the path-id identifies in the SRv6 usage, which covers case 2,
would be helpful. Whether that means the naming should change I leave
to others. We often have names that do not quite fit the evolution of
mechanisms.
Yours,
Joel
On 9/6/2024 8:28 AM, Cheng Li 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>
<mailto:denglijie1...@gmail.com>
*Sent:* Thursday, September 5, 2024 11:08 AM
*To:* spring@ietf.org <mailto: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
