On October 24, 2023 at 9:35:32 PM, 姜文颖 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 https://www.ietf.org/mailman/listinfo/spring
