Subject: [Teas] A review of draft-dong-teas-nrp-scalability

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Jan 2022 16:33:21 -0000

Hi there,

I thought it was about time that I had another look at this draft. 

Thanks to the authors for taking the bold step of changing the file name
of the draft and doing all the updates to get in synch with the network
slicing framework.

I found this document a good overview of the scaling issues with network
resource partitions, but also a helpful link between the two TEAS
technologies: VPN+ and slicing. This material is quite close to the
slicing framework document, and should (IMHO) be considered seriously by
the working group, but it is clearly too much to be inserted into the 
framework, so it is correct to have it as a separate document.

What follows is a few main points and a few minor points, and then a lot
of nits. (Please forgive me for fixing the English, but it is a habit I
can't break.)

Best,
Adrian

== Main points ==

The thing I found missing was the context for counting the number of 
NRPs that may be needed. Are you looking at "the Internet", a tier 1
ISP, a tier 2, or what? This is particularly noticeable when you compare
with the number of VPNs "in the network" (which network?).

---

Section 2 has Figure 1 and a paragraph immediately before it all about
the S-NSSAI. I think you are trying to make two points:
- there is scope in the numbering scheme for potentially very many 5G
  network slices.
- the mapping of 5G slice to IETF slice used to support the 5G slices
  may be n:1 where n could be 1.

However, you don't need to provide as much detail, and you need to give
some more clarity about the mapping.  For example, you could drop 
Figure 1 (which is a duplication from the 3GPP document) and reduce the
text to:

   The 3GPP defines an identifier for a 5G network slice using an 8-bit
   slice/service type and a 24-bit differentiator. This allows mobile
   networks (the RAN and mobile core networks) to potentially support a
   large number of 5G network slices.  It is likely that multiple 5G 
   network slices are mapped to the same IETF network slice, but in some
   cases (for example, for specific slice/service types) the mapping may
   be closer to one-to-one and the required network resource partitions
   may increase as well.

---

It seems to me that Section 3.3 positions itself to examine multiple
possible solutions, but then only actually addresses one potential
solution. Probably, you should move this text into a subsection called
"Resource Aware Segment Identifiers", and you should start 3.3 with...

   This section provides a gap analysis for existing and potential
   mechanisms to perform network resource partition identification in
   the control and data planes.  Further mechanisms may be added in a 
   future version of this document.

== Minor points ==

Section 2 ends with 

   Thus realization of IETF network slices needs to meet the scalability
   requirement of IETF network slice services in different scenarios.
   The increased number of IETF network slice services will introduce
   additional complexity and overhead both to the control plane and the
   data plane, especially in the aspects related to the underlay network
   resource partitions.  Although in many cases multiple IETF network
   slice services can be mapped to the same network resource partition,
   there still can be scalability challenges with the increased number
   of network resource partitions.

It's all true (even if there are a lot of words), but you have said most
of this in section 1. Furthermore, I think you need to establish the 
scaling requirements. Perhaps you can reduce this quite a bit...

   Thus, there may be large numbers of IETF network Slices in some
   scenarios and the realization of IETF Network Slices needs to meet 
   the scalability requirements.  Mapping multiple IETF Network Slices 
   to the same network resource partition presents a significant scaling
   benefit, but there can still be a requirement for a large number of
   network resource partitions which presents its own scalability 
   challenges. 

---

3.1.1

"may increase dramatically"

Can you give some sense of the drama? Is it linear or exponential? If
exponential, what is the exponent?

---

3.2

   To provide different IETF network slice services with the required
   SLOs and SLEs, it is necessary to allocate different subsets of
   network resources as different network resource partitions to avoid
   or reduce the unexpected interruption.

Not quite clear what might be unexpectedly interrupted and so not clear
why it is necessary to allocate different subsets of network resources.

---

4.1

The final paragraph of this section seems quite important and is not
really related to the work of the previous paragraphs. Perhaps move it
into its own subsection (4.1.1)?

---

6.

I think the security considerations need to consider how a scaling 
attack might be used to make the network function badly or break down
completely. For example, in an automated system, some behaviours (for
example, sending a large number of slightly different packets) could
cause the software to create a very large number of network slices
which would then result in a large number of NRPs.

One protection against this is, of course, to ensure that the NRP
system scales well. Another solution would be recommend that software
controllers/orchestrators are aware of the scaling constraints of the
network and dampen the arrival rate of new slices/NRPs as well as
raising alarms when thresholds are crossed.

== Nits ==

General

You need to decide to use "IETF Network Slice" or "IETF network slice".
draft-ietf-teas-ietf-network-slices aims to use only "IETF Network
Slice".

Similarly, you are inconsistent with respect to "network resource
partition" and "Network Resource Partition."

---

Authors

At some point in the life of this document you are going to get asked to
reduce the author count to 5 or fewer. It is often easier to do this 
early in the life of the document, and certainly it is less painful to
do it yourselves than to have the chairs force it on you.

---

Abstract

s/IETF network slice service aims/The IETF network slice service aims/

s/With the demand for/As the demand for/

s/partition in the network/partitions in the network/

---

1.

s/IETF network slice service aims/The IETF network slice service aims/

s/Enhanced VPN (VPN+) aims/VPN+ aims/

s/which requires connectivity/which require connectivity/

s/meet the requirement VPN+/meet the requirements of VPN+/

s/With the demand for/As the demand for/

s/partition in the network/partitions in the network/

---

2. 

s/different types of services/different types of service/

s/mobile transport service./mobile transport services/

s/broadband service and/broadband services, and/

s/respectively, each/respectively: each/

s/such as multicast service/such as multicast services,/

s/requires to provide/requires the provision of/

s/service performance guarantee/service performance guarantees/

---

3.

OLD
   In this section, the scalability of Network Resource Partition in the
   control plane and data plane is analyzed to understand the possible
   gaps in meeting the scalability requirement of IETF Network Slices.
NEW
   This section analyses the scalability of Network Resource Partitions
   in the control plane and data plane to understand the possible
   gaps in meeting the scalability requirements of IETF Network Slices.
END

---

3.1

OLD
   The control plane of network resource partition could be based on the
   hybrid of a centralized controller and the distributed control plane.
NEW
   The control plane for establishing and managing network resource
   partitions could be based on the hybrid of a centralized controller
   and a distributed control plane.  The subsections that follow 
   consider the scalability of these two approaches: the resultant 
   scalability of the control plane will depend on how the hybrid is
   constructed.
END

---

3.1.1

OLD
   For the delivery of IETF network slice services, it is necessary to
   create multiple network resource partitions, each can be associated
   with a customized logical topology.
NEW
   It is necessary to create multiple network resource partitions for
   the delivery of IETF network slice services.  Each network resource
   partition can be associated with a customized logical topology.
END

---

3.1.1

s/The number of route computation/The number of route computations/

s/(i.e.  SPF/(i.e., SPF/

s/separated control/separate control/

s/(e.g.  IGP/(e.g., IGP/

s/separated network/separate network/

s/It is suggested/it is suggested/

s/choose the control/choose a control/

---

3.1.2

s/introducing the/introducing a/

s/SDN/Software Defined Network (SDN)/

s/partitions requires/partitions require/

---

3.2

s/partition it mapped to/partition it is mapped to/

s/data packet needs/data packet need/

s/(e.g.  IP/(e.g., IP/

s/global-significant/globally-significant/

s/has impact on/has an impact on/

---

3.3

s/build network resource partition/build network resource partitions/

s/number of route computation/number of route computations/

s/(e.g.  SPF computation)/(e.g., SPF computations)/

---

4.1

OLD
   For the distributed control plane, several optimizations can be
   considered to reduce the control plane overhead and improve the
   control plane scalability.
NEW
   Several optimizations can be considered to reduce the distributed 
   control plane overhead and improve its scalability.
END

s/is used for such group of/is used for each such group of/

---

4.1

I think "Figure 1: FIG-2" may be an error :-)

---

4.2

s/and such group/and such groups/

s/(e.g. the/(e.g., the/

---

5.

s/needs to evolve/need to evolve/

---

6.

s/in[I-D./in [I-D./

s/applies to this document/apply to this document/

---

10.1

I think you use RFC 3032 and RFC 8200 in a normative way.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 17 Jan 2022 07:05:06 +0000

Hi Adrian, 

Thanks a lot for the detailed review on this update, currently we are in the process of another revision, thus your comments will be incorporated soon. 

Also please see some replies inline. 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, January 16, 2022 12:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: A review of draft-dong-teas-nrp-scalability
> 
> Hi there,
> 
> Thanks to the authors for taking the bold step of changing the file name of
> the draft and doing all the updates to get in synch with the network slicing
> framework.

After last IETF meeting we received some suggestions about the terminology. Based on the discussion among the authors, we've decided to make this change to better align with the network slicing framework. 

> technologies: VPN+ and slicing. This material is quite close to the slicing
> framework document, and should (IMHO) be considered seriously by the
> working group, but it is clearly too much to be inserted into the framework,
> so it is correct to have it as a separate document.

> What follows is a few main points and a few minor points, and then a lot of
> nits. (Please forgive me for fixing the English, but it is a habit I can't break.)

Thanks, we really appreciate your efforts in making the comments and catching the nits. 

> 
> Best,
> Adrian
> 
> == Main points ==
> 
> The thing I found missing was the context for counting the number of NRPs
> that may be needed. Are you looking at "the Internet", a tier 1 ISP, a tier 2,
> or what? This is particularly noticeable when you compare with the
> number of VPNs "in the network" (which network?).

It is expected that NRPs will be used for one or multiple network domains of one ISP, or multiple network domains which belong to ISPs who have some form of collaboration, but it is not expected to be used for the internet.

As NRPs can be used as the underlay of the VPN services, the scope of NRPs and VPNs can be similar. 

> ---
> 
> Section 2 has Figure 1 and a paragraph immediately before it all about the
> S-NSSAI. I think you are trying to make two points:

Thanks for the suggestion, I agree we can reduce the details about 5G network slice and focus more on the mapping. 

> ---
> 
> It seems to me that Section 3.3 positions itself to examine multiple possible
> solutions, but then only actually addresses one potential solution. Probably,
> you should move this text into a subsection called "Resource Aware
> Segment Identifiers", and you should start 3.3 with...
> 

Sections 3.3 is mainly about the analysis of the scalability limitation in one existing mechanism: the resource aware segment based data plane with MT/Flex-Algo based control plane. The potential mechanisms for improved scalability are described in section 4. 

We could make the title of section 3.3 clearer.

> It's all true (even if there are a lot of words), but you have said most of this
> in section 1. Furthermore, I think you need to establish the scaling
> requirements. Perhaps you can reduce this quite a bit...
> 

Thanks for the suggested text, it looks much better than the old ones:)

> exponential, what is the exponent?

This sentence is a summary of the overhead increase in several control plane aspects. In most cases, the overhead will increase linearly. Will clarify this in next revision. 

> why it is necessary to allocate different subsets of network resources.

This may be a typo. What we meant to say is "unexpected interference". If the network resource is shared with other service, it is possible that the performance is impacted due to resource competition.

> 
> ---
> 
> 4.1
> 
> The final paragraph of this section seems quite important and is not really
> related to the work of the previous paragraphs. Perhaps move it into its
> own subsection (4.1.1)?

OK, we can add 2 subsections under 4.1 for the distributed control plane and centralized control plane optimizations respectively.

> 
> ---
> 
> 6.
> 
> I think the security considerations need to consider how a scaling attack
> might be used to make the network function badly or break down
> example, sending a large number of slightly different packets) could cause
> the software to create a very large number of network slices which would
> then result in a large number of NRPs.
> 
> One protection against this is, of course, to ensure that the NRP system
> scales well. Another solution would be recommend that software
> network and dampen the arrival rate of new slices/NRPs as well as raising
> alarms when thresholds are crossed.

We will add some text about scaling attack to the security considerations.

> == Nits ==

Thanks for catching the nits, will fix them in next revision.

Best regards,
Jie

> draft-ietf-teas-ietf-network-slices aims to use only "IETF Network Slice".
> 
> Similarly, you are inconsistent with respect to "network resource partition"
> and "Network Resource Partition."
> 
> ---
> 
> Authors
> 
> reduce the author count to 5 or fewer. It is often easier to do this early in
> the life of the document, and certainly it is less painful to do it yourselves
> than to have the chairs force it on you.
> 
> ---
> 
> Abstract
>