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>收件人："姜文颖" <jiangweny...@chinamobile.com>抄 送: 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>发送时间：2024-04-03 03:21:10主题：Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segmentsOn October 24, 2023 at 9:35:32PM, 姜文颖 wrote:[Your reply had changed the subject, so my filters didn39t 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 39layer-3 adjacency39, 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 you39re defining a new behavior. However, yourdescription (last two sentences above) mirrors whatI-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 sameuse 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 resourcesI-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 inI-D.ietf-spring-resource-aware-segments? [To the authors ofI-D.ietf-spring-resource-aware-segments: it might be useful explainhow the draft addresses the use case in§3/I-D.cheng-spring-srv6-policy-resource-gurantee.] [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 otherresource-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. 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 listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/springSubject：Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segmentsOn October 24, 2023 at 9:35:32PM, 姜文颖 wrote:[Your reply had changed the subject, so my filters didn39t 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 39layer-3 adjacency39, 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 you39re defining a new behavior. However, yourdescription (last two sentences above) mirrors whatI-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 sameuse 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 resourcesI-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 inI-D.ietf-spring-resource-aware-segments? [To the authors ofI-D.ietf-spring-resource-aware-segments: it might be useful explainhow 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 otherresource-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 listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
