To make sure I am understanding your reasoning....
It appears to me that you are saying that as you understand
draft-ietf-spring-resource-aware-segments, it does not allow for using
different SIDs on the same node to represent sending different sets of
traffic through different queues on the same interface. And you
consider that the primary driver for
draft-cheng-spring-srv6-policy-resource-guanateee?
Yours,
Joel
On 4/27/2024 4:16 AM, Wenying Jiang wrote:
Hi Alvaro,
Thank you for your valuable comments.
Let's conduct the following technical comparative analysis:
1. How to ensure resources:
1.1: Different interfaces;
1.2: Different topologies;
1.3: Different paths;
1.4: Different resource queues under the same interface, such as queues.
2. Let's first examine the existing technologies:
Different labels correspond to different interfaces, and the resources vary on
different interfaces.
Different SRv6 locators or prefix-sids (node labels) traverse interfaces with
different resources in different IGP topologies or on different flex-algos of
different IGPs.
Different paths of different SR Policies represent different resources.
Summary: Current technologies can solve the issues mentioned in 1.1 to 1.3.
3. Next, let's consider draft-ietf-spring-resource-aware-segments:
It doesn't introduce any specific extensions, but rather provides a summary of
existing technologies by naming labels and SRv6 SIDs as resources.
Without this draft, the existing technologies can already be implemented,
making this draft purely informational.
Summary: draft-ietf-spring-resource-aware-segments merely summarizes the
technologies mentioned in 1.1 to 1.3 and provides resource SID naming without
fundamental changes.
4.
Finally, let's explore the need for new SRv6 forwarding behaviors, taking the example of reserving resources for
queues on network devices:
When different queues require
reserved resources under the same interface, END.X
needs to be allocated for each queue. However, the current RFC8986
does not define this forwarding behavior.
When forwarding SRv6 locators, it is a standard IPv6 route with the egress interface as a layer 3 logical port, which cannot be mapped to specific
queues on an interface.
Summary: Therefore, in SRv6, we need to redefine new forwarding behaviors
corresponding to resources.
BR.
Wenying
----邮件原文----
发件人：Alvaro Retana <aretana.i...@gmail.com>
收件人：Wenying Jiang <jiangweny...@chinamobile.com>,"Dongjie (Jimmy)"
<jie.d...@huawei.com>
抄 送: draft-cheng-spring-s
<draft-cheng-spring-srv6-policy-resource-guran...@ietf.org>,chengweiqiang
<chengweiqi...@chinamoblie.com>,spring-chairs
<spring-cha...@ietf.org>,draft-ietf-spring-re
<draft-ietf-spring-resource-aware-segme...@ietf.org>,spring
<spring@ietf.org>
发送时间：2024-04-24 02:51:30
主题：RE: Re:Re: [spring] Relationship
betweendraft-cheng-spring-srv6-policy-resource-guranteeanddraft-ietf-spring-resource-aware-segments
On April 22, 2024 at 2:46:00AM, Dongjie (Jimmy) wrote:
Jie:
Hi!
...
> [Jie] In my understanding, both documents propose enhancements to SR to solve
> the requirements for resource guarantee in SR networks.
>
> The essential is that SR SIDs can be used to indicate not only the function
> (or behavior) to be performed, but also to indicate the set of resources used
> to perform the function (or behavior). Thus these SIDs are called
> resource-aware SIDs. From this perspective, it is true that
> draft-ietf-spring-resource-aware-segments is the framework for introducing
> resource-awareness to SR.
>
> As for the solutions for resource-guaranteed SR Policy, there can be
> different approaches to indicate the SIDs are resource-aware:
>
> The first approach is as described in
> draft-ietf-spring-resource-aware-segments, the SR-MPLS SIDs or SRv6 locators
> are associated with a set of network resources, this allows SR SIDs with all
> existing types/behaviors be associated with specific set of network resources
> for packet processing. Thus this draft provides a general solution for
> resource-aware SIDs, which can apply to SR Policies with explicit or loose
> paths, SR Flex-Algo, SR Multi-topology, etc.
>
> The second approach is as described in
> draft-cheng-spring-srv6-policy-resource-gurantee for SRv6, a SRv6 new
> behavior is defined as a variant of End.X, which indicates “End.X with
> specific set of link resource”(maybe the behavior could be renamed as
> End.XNRP?) This approach applies to SRv6 Policies built with End.X SIDs only.
>
> Thus in my view draft-cheng-spring-srv6-policy-resource-gurantee aligns with
> the resource-aware SR framework as specified in
> draft-ietf-spring-resource-aware-segments, while it focuses on a specific use
> case: enhancements to SRv6 Policy explicit paths for resource guarantee, and
> provides an optional extension for that use case.
You seem to be saying that each approach "aligns with the
resource-aware SR framework as specified in
draft-ietf-spring-resource-aware-segments", even if the approach in
draft-cheng-spring-srv6-policy-resource-gurantee is not addressed in
draft-ietf-spring-resource-aware-segments. Is that your point?
I'm confused because you also say that the solution in
draft-ietf-spring-resource-aware-segments can apply to any scenario
("general solution for resource-aware SIDs, which can apply to SR
Policies with explicit or loose paths, SR Flex-Algo, SR
Multi-topology, etc."), which I assume includes the use case in
draft-cheng-spring-srv6-policy-resource-gurantee. Is that correct?
If so, why is an approach that "applies to SRv6 Policies built with
End.X SIDs only" needed?
Thanks!
Alvaro.
Subject：RE: Re:Re: [spring] Relationship
betweendraft-cheng-spring-srv6-policy-resource-guranteeanddraft-ietf-spring-resource-aware-segments
On April 22, 2024 at 2:46:00AM, Dongjie (Jimmy) wrote:
Jie:
Hi!
...
> [Jie] In my understanding, both documents propose enhancements to SR to solve
> the requirements for resource guarantee in SR networks.
>
> The essential is that SR SIDs can be used to indicate not only the function
> (or behavior) to be performed, but also to indicate the set of resources used
> to perform the function (or behavior). Thus these SIDs are called
> resource-aware SIDs. From this perspective, it is true that
> draft-ietf-spring-resource-aware-segments is the framework for introducing
> resource-awareness to SR.
>
> As for the solutions for resource-guaranteed SR Policy, there can be
> different approaches to indicate the SIDs are resource-aware:
>
> The first approach is as described in
> draft-ietf-spring-resource-aware-segments, the SR-MPLS SIDs or SRv6 locators
> are associated with a set of network resources, this allows SR SIDs with all
> existing types/behaviors be associated with specific set of network resources
> for packet processing. Thus this draft provides a general solution for
> resource-aware SIDs, which can apply to SR Policies with explicit or loose
> paths, SR Flex-Algo, SR Multi-topology, etc.
>
> The second approach is as described in
> draft-cheng-spring-srv6-policy-resource-gurantee for SRv6, a SRv6 new
> behavior is defined as a variant of End.X, which indicates “End.X with
> specific set of link resource”(maybe the behavior could be renamed as
> End.XNRP?) This approach applies to SRv6 Policies built with End.X SIDs only.
>
> Thus in my view draft-cheng-spring-srv6-policy-resource-gurantee aligns with
> the resource-aware SR framework as specified in
> draft-ietf-spring-resource-aware-segments, while it focuses on a specific use
> case: enhancements to SRv6 Policy explicit paths for resource guarantee, and
> provides an optional extension for that use case.
You seem to be saying that each approach "aligns with the
resource-aware SR framework as specified in
draft-ietf-spring-resource-aware-segments", even if the approach in
draft-cheng-spring-srv6-policy-resource-gurantee is not addressed in
draft-ietf-spring-resource-aware-segments. Is that your point?
I'm confused because you also say that the solution in
draft-ietf-spring-resource-aware-segments can apply to any scenario
("general solution for resource-aware SIDs, which can apply to SR
Policies with explicit or loose paths, SR Flex-Algo, SR
Multi-topology, etc."), which I assume includes the use case in
draft-cheng-spring-srv6-policy-resource-gurantee. Is that correct?
If so, why is an approach that "applies to SRv6 Policies built with
End.X SIDs only" needed?
Thanks!
Alvaro.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
