Re: [Teas] Considerations and request for adoption of draft-dong-teas-nrp-scalability

Hi Dhruv,

Thanks for your review and questions, please see some replies inline with [Jie]:

From: Dhruv Dhody [mailto:dhruv.ietf@gmail.com]
Sent: Wednesday, April 27, 2022 5:16 PM
To: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>
Cc: teas@ietf.org; TEAS WG Chairs <teas-chairs@ietf.org>; draft-dong-teas-nrp-scalability@ietf.org
Subject: Re: [Teas] Considerations and request for adoption of draft-dong-teas-nrp-scalability

Hi Jie,

I had a look at the draft. Overall I think the draft is in a good shape for the WG to take over and enhance!

Please find my comments -

Is there any consideration that needs to be given to how many IETF network slices can map to an NRP and still be able to meet the individual SLO/SLE for each IETF network slice? It is of course dependent on the SLO/SLE but it is something to also consider while analyzing the scalability of the NRPs. I suggest adding text for this!

[Jie] As you said this number highly depends on the SLO/SLE of the network slices, and the operator’s policy. We could add some text about the possible inputs to the mapping decision.

Section 3.1.1, Is a separate IGP instance per NRP mentioned only in theory, or is it really practical to do it in some deployments? If it is in theory maybe we can add text to say that?

[Jie] I believe there are deployments of the separate IGP instances mechanism.

Section 4.1.1, can a practical example of the second optimization be provided? Perhaps two NRPs are both based on a single MT or FlexAlgo but different resources can be spelled out more clearly as examples?

[Jie] Figure 1 in section 4.1.1 gives an example of 2 NRPs share the same topology (can be defined using either MT or Flex-Algo) but different resources. We can add some more text to improve the readability.

Section 4.2, the first paragraph to me is generic and applicable to the control plane as well. Not sure why it is in this section.

[Jie] Here the first paragraph is to indicate that proper aggregation of more network slice services to the same NRP can help to reduce the scalability challenge to the data plane. But I agree this text is generic and can be moved to say the beginning of section 4.

Section 5, a suggestion to add a disclaimer that this section focuses on SR-based NRP. Various other NRP realizations techniques are also possible.

[Jie] OK, we can add something like this : This section takes the evolution of SR based NRP solution as an example, while the analysis and optimizations in document is generic and not specific to SR.

I suggest adding Operational considerations with respect to the configuration needed for NRPs.

[Jie] Good suggestion. We will consider the scalability implications in NRP operation and add it in a future version.

Nits
- Expand on first use - SPF, SR, SRv6, SID, etc

[Jie] thanks, will fix them in next version.

Best regards,
Jie

Thanks!
Dhruv

On Thu, Apr 21, 2022 at 1:48 PM Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:

Hi Chairs and all,

draft-dong-teas-nrp-scalability was presented in TEAS session of IETF 113 meeting, after the presentation, the authors requested (again) for the WG adoption. Please note the adoption request has been sent to the TEAS list in February:

https://mailarchive.ietf.org/arch/msg/teas/cmd5Ub7nCDoEzqkFtiq20LyjXtI/

As indicated in the slides, the recent updates are: terminology alignment, adding new coauthors and editorial changes to resolve the received comments. The major content of the draft has been quite stable and presented several times to the WG.

Actually the authors have requested for adoption on IETF 112, at that time the response from WG chairs was that the adoption call will be taken to the list. While on IETF 113 the Chairs’ opinion was “allow some time for on-list discussion before polling for adoption”.

Recently on the list we had some discussion about the NRP definition and realizations, which shows interest in the NRP realization topic. And this document would be fairly useful for realizing NRPs in a scalable manner.

The authors welcome more discussion on the list, and considers the adoption call as the best way to trigger further discussion. Thus we would like to solicit the WG chairs to start the adoption call on this document, thanks.

Best regards,

Jie

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas