Hi Alvaro,
Thank you for your valuable comments.
Let39s conduct the following technical comparative analysis:
1. How to ensure resources:1.1: Different interfaces1.2: Different
topologies1.3: Different paths1.4: Different resource queues under the same
interface, such as queues.2. Let39s 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, let39s
consider draft-ietf-spring-resource-aware-segments:It doesn39t 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, let39s 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-segmentsOn
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 theresource-aware SR framework as specified
indraft-ietf-spring-resource-aware-segments", even if the approach
indraft-cheng-spring-srv6-policy-resource-gurantee is not addressed
indraft-ietf-spring-resource-aware-segments. Is that your point?I39m confused
because you also say that the solution
indraft-ietf-spring-resource-aware-segments can apply to any scenario("general
solution for resource-aware SIDs, which can apply to SRPolicies with explicit
or loose paths, SR Flex-Algo, SRMulti-topology, etc."), which I assume includes
the use case indraft-cheng-spring-srv6-policy-resource-gurantee. Is that
correct?If so, why is an approach that "applies to SRv6 Policies built
withEnd.X SIDs only" needed?Thanks!Alvaro.Subject：RE: Re:Re: [spring]
Relationship
betweendraft-cheng-spring-srv6-policy-resource-guranteeanddraft-ietf-spring-resource-aware-segmentsOn
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 theresource-aware SR framework as specified
indraft-ietf-spring-resource-aware-segments", even if the approach
indraft-cheng-spring-srv6-policy-resource-gurantee is not addressed
indraft-ietf-spring-resource-aware-segments. Is that your point?I39m confused
because you also say that the solution
indraft-ietf-spring-resource-aware-segments can apply to any scenario("general
solution for resource-aware SIDs, which can apply to SRPolicies with explicit
or loose paths, SR Flex-Algo, SRMulti-topology, etc."), which I assume includes
the use case indraft-cheng-spring-srv6-policy-resource-gurantee. Is that
correct?If so, why is an approach that "applies to SRv6 Policies built
withEnd.X SIDs only" needed?Thanks!Alvaro.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
