Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments

[Alvaro Retana <[e-mail]>]

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.