On April 21, 2024 at 9:56:07 PM, Wenying Jiang wrote: Wenying:
Hi! ... > > 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.] > [Wenying] The relationship between these two drafts is as follows: ... It is important for you to clearly and explicitly explain what cannot be done with the solution in I-D.ietf-spring-resource-aware-segments that requires your draft. Continuing to talk about your interpretation of the drafts is not getting us anywhere. What use cases cannot be addressed with the existing solution in I-D.ietf-spring-resource-aware-segments? Please be detailed. > 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. [To be clear, a thread in the mailing list can't always be referred to as "consensus".] As far as I can see, the framework in I-D.ietf-spring-resource-aware-segments explains a solution that can address the specific use case in I-D.cheng-spring-srv6-policy-resource-gurantee. Please explain how/why the framework/solution in I-D.ietf-spring-resource-aware-segments cannot address that use case. Note that I-D.ietf-spring-resource-aware-segments proposes allocating a resource-aware SRv6 Locator for each set of network resources (keeping the existing behaviors). OTOH, I-D.cheng-spring-srv6-policy-resource-gurantee doesn't follow that guidance because it proposes allocating a SID with the End.NRP behavior for each set of network resources. What I'm trying to figure out is whether the extra work is needed. Again, which cases cannot be addressed using I-D.ietf-spring-resource-aware-segments? ... > > 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. I take this explanation to be a "yes" answer to the question: yes, other resource-aware behaviors will need to be defined in the future. I am still hoping to hear technical arguments that justify the work. Thanks! Alvaro. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
