Hi Alvaro,
Thanks a lot for your comments. 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>,"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>发送时间：2023-10-13 21:52:59主题：Re: [spring] Relationshipbetweendraft-cheng-spring-srv6-policy-resource-guranteeanddraft-ietf-spring-resource-aware-segmentsOn October 12, 2023 at 11:37:01 PM, 姜文颖 wrote:WenYing:Hi!> We received the similar comments before IETF 107 [1] and the authors of both> drafts had worked together to resolve it in the latest version. We has> clarified the scope in draft-cheng and has changed the name of the draft to> "draft-cheng-spring-srv6-policy-resource-guarantee" to better differentiate> the two drafts. The authors of both drafts have reached a consensus and> recommend that WG proceed with them separately.Consensus needs to be reached within the WG, not between authors.This thread is precisely so the WG Chairs can determine what the WGconsiders the best path forward.The scope and new name didn39t help me with my questions: "Is thisdocument an instantiation of a use case already covered byI-D.ietf-spring-resource-aware-segments, or is it a new application? [Wenying] Yes. This is a new application. It is not cover by I-D.ietf-spring-resource-aware-segments. Do we need this new extension, or isI-D.ietf-spring-resource-aware-segments enough? Why do we need aseparate document? Should the use case defined here be part of thealready 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. The use case defined here is not include in the already adopted document. I expect to hear technical arguments that clarify the relationship andjustify having a separate document. I also expect other WGparticipants (not just the authors) to express their opinions.> The main differences are as follows：>> Draft #1 draft-ietf-spring-resource-aware-segments>> This draft extends the SR paradigm by associating SIDs with network resource> attributes，and specific behaviors and actual application application> scenarios are not defined.>>> Draft #2 draft-cheng-spring-srv6-policy-resource-gurantee>> Based on draft-ietf-spring-resource-aware-segments，This draft further defines> specific behaviors, and actual application application scenarios for End.NRP> behavior. This draft can provide guidance when deploying. The SRv6 END.NRP> functional mechanism has a running code, and China Mobile has completed the> verification of this function.Based on this characterization, let me ask for a little more detail(related to the original questions):- draft-cheng-spring-srv6-policy-resource-gurantee "draft furtherdefines specific behaviors, and actual application", so it is notdefining a new concept -- it is providing additional details(behaviors/applications) not present indraft-ietf-spring-resource-aware-segments. Is this a correctassessment? [Wenying] No. Draft-cheng-spring-srv6-policy-resource-gurantee not only defines the specific behavior and practical application but also provides implementable solutions for its practical applications. - draft-cheng-spring-srv6-policy-resource-gurantee defines a newbehavior (END.NRP). Why is this new behavior needed? Why can39t thesame (or similar) result not be achieved usingdraft-ietf-spring-resource-aware-segments (and existing behaviors)? [Wenying] There are several reasons why the new behavior is needed: 1. 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. 2. Define a new behavior that does not change the semantics of existing END.X and that avoids impacting existing networks that have already deployed END.X - If the additional details are necessary, why do we need a separatedocument? IOW, why can39t these details be added todraft-ietf-spring-resource-aware-segments? [Wenying] Based on the inline analysis above, the two drafts have different purposes and different solution, so it was considered more appropriate to have separate document. To be clear. Because this document is closely related to analready-adopted WG document, we (chairs) must be diligent about anyoverlap. That is the primary purpose of these questions, given thatyou asked for adoption.Even though this document is far from needing an ImplementationDescription [1], please add text to the draft describing the existingcode. Note that existing code does not guarantee adoption. [Wenying] OK. The Implementation status have been added in section 5 of the updated version 02： https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-policy-resource-gurantee/02/ Thanks!Alvaro.[1] https://wiki.ietf.org/en/group/spring/WG_Policies_______________________________________________spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/springSubject：Re: [spring] Relationshipbetweendraft-cheng-spring-srv6-policy-resource-guranteeanddraft-ietf-spring-resource-aware-segmentsOn October 12, 2023 at 11:37:01 PM, 姜文颖 wrote:WenYing:Hi!> We received the similar comments before IETF 107 [1] and the authors of both> drafts had worked together to resolve it in the latest version. We has> clarified the scope in draft-cheng and has changed the name of the draft to> "draft-cheng-spring-srv6-policy-resource-guarantee" to better differentiate> the two drafts. The authors of both drafts have reached a consensus and> recommend that WG proceed with them separately.Consensus needs to be reached within the WG, not between authors.This thread is precisely so the WG Chairs can determine what the WGconsiders the best path forward.The scope and new name didn39t help me with my questions: "Is thisdocument an instantiation of a use case already covered byI-D.ietf-spring-resource-aware-segments, or is it a new application?Do we need this new extension, or isI-D.ietf-spring-resource-aware-segments enough? Why do we need aseparate document? Should the use case defined here be part of thealready adopted document?"I expect to hear technical arguments that clarify the relationship andjustify having a separate document. I also expect other WGparticipants (not just the authors) to express their opinions.> The main differences are as follows：>> Draft #1 draft-ietf-spring-resource-aware-segments>> This draft extends the SR paradigm by associating SIDs with network resource> attributes，and specific behaviors and actual application application> scenarios are not defined.>>> Draft #2 draft-cheng-spring-srv6-policy-resource-gurantee>> Based on draft-ietf-spring-resource-aware-segments，This draft further defines> specific behaviors, and actual application application scenarios for End.NRP> behavior. This draft can provide guidance when deploying. The SRv6 END.NRP> functional mechanism has a running code, and China Mobile has completed the> verification of this function.Based on this characterization, let me ask for a little more detail(related to the original questions):- draft-cheng-spring-srv6-policy-resource-gurantee "draft furtherdefines specific behaviors, and actual application", so it is notdefining a new concept -- it is providing additional details(behaviors/applications) not present indraft-ietf-spring-resource-aware-segments. Is this a correctassessment?- draft-cheng-spring-srv6-policy-resource-gurantee defines a newbehavior (END.NRP). Why is this new behavior needed? Why can39t thesame (or similar) result not be achieved usingdraft-ietf-spring-resource-aware-segments (and existing behaviors)?- If the additional details are necessary, why do we need a separatedocument? IOW, why can39t these details be added todraft-ietf-spring-resource-aware-segments?To be clear. Because this document is closely related to analready-adopted WG document, we (chairs) must be diligent about anyoverlap. That is the primary purpose of these questions, given thatyou asked for adoption.Even though this document is far from needing an ImplementationDescription [1], please add text to the draft describing the existingcode. Note that existing code does not guarantee adoption.Thanks!Alvaro.[1] https://wiki.ietf.org/en/group/spring/WG_Policies_______________________________________________spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
