Hi Alvaro and Wenying, Sorry for the delayed reply on this.
Speaking as the coauthor of draft-ietf-spring-resource-aware-segments, please see some replies inline with [Jie]: Best regards, Jie From: Wenying Jiang [mailto:jiangweny...@chinamobile.com] Sent: Monday, April 22, 2024 9:56 AM To: Alvaro Retana <aretana.i...@gmail.com> Cc: draft-cheng-spring-s <draft-cheng-spring-srv6-policy-resource-guran...@ietf.org>; chengweiqiang <chengweiqi...@chinamoblie.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; spring-chairs <spring-cha...@ietf.org>; draft-ietf-spring-re <draft-ietf-spring-resource-aware-segme...@ietf.org>; spring <spring@ietf.org> Subject: Re:Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments Hi Alvaro, Thanks for your insightful questions on this draft. My responses are inline below with [Wenying]. B.R. Wenying ----邮件原文---- 发件人：Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> 收件人："姜文颖" <jiangweny...@chinamobile.com<mailto:jiangweny...@chinamobile.com>> 抄 送: draft-cheng-spring-s <draft-cheng-spring-srv6-policy-resource-guran...@ietf.org<mailto:draft-cheng-spring-srv6-policy-resource-guran...@ietf.org>>,chengweiqiang <chengweiqi...@chinamoblie.com<mailto:chengweiqi...@chinamoblie.com>>,"Dongjie (Jimmy)" <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>,spring-chairs <spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>>,draft-ietf-spring-re <draft-ietf-spring-resource-aware-segme...@ietf.org<mailto:draft-ietf-spring-resource-aware-segme...@ietf.org>>,spring <spring@ietf.org<mailto:spring@ietf.org>> 发送时间：2024-04-03 03:21:10 主题：Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments On October 24, 2023 at 9:35:32PM, 姜文颖 wrote: [Your reply had changed the subject, so my filters didn't catch it. :-( Changing the subject back to the original.] Wenying: Hi! Following up from the discussion @ IETF 119. ... > > Do we need this new extension, or is > > I-D.ietf-spring-resource-aware-segments enough? Why do we need a separate > > document? Should the use case defined here be part of the already adopted > > document? > > [WenYing] RFC8986 Section 4.2 End.X forwards to an endpoint with > cross-connect to a 'layer-3 adjacency', as well as L2 bundle members of an > L3 LAG interface. > > I-D.ietf-spring-resource-aware-segments extends the SR paradigm by > associating SIDs with network resource attributes, but specific behaviors > and actual application application scenarios are not defined. > > Compared to end.X, the forwarding behavior has been changed, according to > RFC8986, we need to clearly define its behavior to make the forwarding > instructions clear. > > This document defines the following behavior: > > Any SID instance of End.NRP behavior is associated with two sets：J1 and J2. > > J1：one or more L3 adjacencies > > J2：NRP of J1 > > The End.NRP SID therefore can be used to build SR paths or virtual networks > with a set of reserved network resources. > > It can be used to identify the set of network resources allocated on the > segments for packet processing. I understand that you're defining a new behavior. However, your description (last two sentences above) mirrors what I-D.ietf-spring-resource-aware-segments already defines: The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource- aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. It is not clear to me that the two mechanisms cannot solve the same use cases. The difference is in this detail: I-D.cheng-spring-srv6-policy-resource-gurantee: proposes allocating a SID with the End.NRP behavior for each set of network resources I-D.ietf-spring-resource-aware-segments: proposes allocating a resource-aware SRv6 Locator for each set of network resources (keeping the existing behaviors) What use cases cannot be addressed with the existing solution in I-D.ietf-spring-resource-aware-segments? [To the authors of I-D.ietf-spring-resource-aware-segments: it might be useful explain how the draft addresses the use case in §3/I-D.cheng-spring-srv6-policy-resource-gurantee.] [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. [Wenying] The relationship between these two drafts is as follows: I-D.ietf-spring-resource-aware-segments serves as a valuable framework document, offering common architectural ground for development without defining any solution itself. It is recognized as a useful framework in providing guidance for development. However, specific solutions are still needed. On the other hand,I-D.cheng-spring-srv6-policy-resource-gurantee proposes specific solutions by defining particular behaviors, such as the End.NRP behavior, and presents actual application scenarios. This draft can guide deployments, and the SRv6 END.NRP functional mechanism has been implemented and verified by China Mobile. Based on discussions in the mailing list, there is a consensus that I-D.ietf-spring-resource-aware-segments functions more as a framework without providing specific solutions. Therefore, it may not address the specific use cases described in Section 3 of I-D.cheng-spring-srv6-policy-resource-gurantee. For further reference, you can find the discussion mailing list links below： ⦁https://mailarchive.ietf.org/arch/msg/spring/K4-yldPkaKOMiChxf3CrvwCrHko/ ⦁https://mailarchive.ietf.org/arch/msg/spring/q91kDe7AfKgx9RhQUL76BwhN8dQ/ ⦁https://mailarchive.ietf.org/arch/msg/spring/uJHMRdi1MlXozjw7wqZkKvJKYtw/ ⦁https://mailarchive.ietf.org/arch/msg/spring/fr-OPpzlddgz86LfSKEtKAmaHd4/ ⦁https://mailarchive.ietf.org/arch/msg/spring/DHvMPJETp-ivUmOb--d31POEKk4/ The End.NRP behavior is a variation of the End.X behavior. Will other resource-aware behaviors also need to be defined in the future? [Wenying] When there are high service quality requirements from customers, operators may use network slicing with resource guarantees to ensure the expected quality. Typically, the determination of path and resource guarantees is made simultaneously to achieve the desired quality assurance for the customers. The End.NRP behavior primarily serves SRv6 Policy strict-path scenarios and is a variation of the End.X behavior designed to meet the strict quality assurance requirements of the aforementioned customers. Additionally, End.NRP can be associated with multiple resources. Currently, there is no immediate need to define other variants of the behavior. [Jie] Following the solution in draft-ietf-spring-resource-aware-segments, no new SR behavior is needed for introducing resource-awareness. As mentioned before: > > I expect to hear technical arguments that clarify the relationship and > > justify having a separate document. I also expect other WG > > participants (not just the authors) to express their opinions. Thanks! Alvaro. _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring Subject：Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments On October 24, 2023 at 9:35:32PM, 姜文颖 wrote: [Your reply had changed the subject, so my filters didn't catch it. :-( Changing the subject back to the original.] Wenying: Hi! Following up from the discussion @ IETF 119. ... > > Do we need this new extension, or is > > I-D.ietf-spring-resource-aware-segments enough? Why do we need a separate > > document? Should the use case defined here be part of the already adopted > > document? > > [WenYing] RFC8986 Section 4.2 End.X forwards to an endpoint with > cross-connect to a 'layer-3 adjacency', as well as L2 bundle members of an > L3 LAG interface. > > I-D.ietf-spring-resource-aware-segments extends the SR paradigm by > associating SIDs with network resource attributes, but specific behaviors > and actual application application scenarios are not defined. > > Compared to end.X, the forwarding behavior has been changed, according to > RFC8986, we need to clearly define its behavior to make the forwarding > instructions clear. > > This document defines the following behavior: > > Any SID instance of End.NRP behavior is associated with two sets：J1 and J2. > > J1：one or more L3 adjacencies > > J2：NRP of J1 > > The End.NRP SID therefore can be used to build SR paths or virtual networks > with a set of reserved network resources. > > It can be used to identify the set of network resources allocated on the > segments for packet processing. I understand that you're defining a new behavior. However, your description (last two sentences above) mirrors what I-D.ietf-spring-resource-aware-segments already defines: The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource- aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. It is not clear to me that the two mechanisms cannot solve the same use cases. The difference is in this detail: I-D.cheng-spring-srv6-policy-resource-gurantee: proposes allocating a SID with the End.NRP behavior for each set of network resources I-D.ietf-spring-resource-aware-segments: proposes allocating a resource-aware SRv6 Locator for each set of network resources (keeping the existing behaviors) What use cases cannot be addressed with the existing solution in I-D.ietf-spring-resource-aware-segments? [To the authors of I-D.ietf-spring-resource-aware-segments: it might be useful explain how the draft addresses the use case in §3/I-D.cheng-spring-srv6-policy-resource-gurantee.] The End.NRP behavior is a variation of the End.X behavior. Will other resource-aware behaviors also need to be defined in the future? As mentioned before: > > I expect to hear technical arguments that clarify the relationship and > > justify having a separate document. I also expect other WG > > participants (not just the authors) to express their opinions. Thanks! Alvaro. _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
