Re: [Teas] [**EXTERNAL**] Review of draft-geng-teas-network-slice-mapping

["Rokui, Reza" <[e-mail]>]

Hi Adrian and authors,

Agreed with your proposal. As one potential suggestion, the following draft might be used as a basis for the new applicability document.
Please reach out if there are any suggestions/comments.

 https://datatracker.ietf.org/doc/html/draft-rokui-5g-ietf-network-slice-00

Cheers,
Reza

From: Adrian Farrel <[e-mail]>
Date: Monday, May 23, 2022 at 8:39 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [**EXTERNAL**] Review of draft-geng-teas-network-slice-mapping
Hi authors,

I'm not a 5G expert, but I think that given the work that 3GPP has
been doing on slicing, and given the role that an "IETF network slice"
is expected to play in support of a 3GPP slice, I think it is important
for TEAS to work on an informational document to show the applicability
of IETF slices in the 3GPP context.

My review here focuses on three aspects:
- how the document should be positioned
- alignment with the slicing framework document
- nits (as usual)

I hope it helps, and maybe the chairs would consider getting something
adopted so the WG can continue the work.

Best,
Adrian

===

I think what you have here is an Applicability Statement, and it is
(should be) constrained by the use of IETF technologies in the role of a
"transport network". Since the term "transport network" is heavily over-
used, perhaps we can focus on "5G transport network slices". Thus, the
document title might be better as:

  Applicability of IETF Network Slices in the Role of 5G Transport
    Network Slices in Support of 5G End-to-end Network Slices

The words about what this document does (in the abstract and
introduction) might be re-shaped accordingly.

---

Abstract

s/5G.  End-to-end/5G.  An end-to-end/
s/draft/document/ (twice)
s/intends to expose/exposes/

---

Requirements Language

You can remove this from the document header (it is already present in
Section 2. But please also use the up-to-date form of the text.

---

1.

s/Network slice contains/A network slice contains/
s/resources(e.g./resources (e.g.,/
s/Transport network is/The Transport network is/
s/for transport network can/for the transport network can/
s/which requests transport/which requires the transport/
s/Objectives SLOs)/Objectives (SLOs)/
s/an IETF network slices in/an IETF network slice in an/
s/procedure for lifecycle/procedure for the lifecycle/
s/to map end-to-end/to map an end-to-end/
s/draft/document/
s/in management/in the management/

---

You need to decide whether "transport network" is capitalised and apply
this consistently throughout the document.

---

2.

Add:
e2e

---

3.

s/The following figure/Figure 1/
s/contains AN/contains an AN/
s/Slices. 3GPP/Slices.  3GPP/
s/called S-NSSAI/called the S-NSSAI/
s/Figure-1/Figure 1/
s/and 02333333/and 03333333/

---

Please check the capitalisation of "IETF network slice" and make it
consistent throughout the document.

---

Figure 1 gives the impression that

- A slice may be supported by one or more CNs
- Each CN may be supported by exactly one TN
- Each TN gives access to exactly one AN
- More than one TN may give access to a single AN

It may help to actually list all of the relationships and give a
clear statement of the 1:1, 1:n, n:1, and m:n relationships.

---

4.

3GPP TR 28.801 needs a reference

---

4.

   Referring to 3GPP TR 28.801, the management of 5G e2e network slices
   from 3GPP view is shown in Figure-2(A).  Figure-2(B) illustrates the
   view of IETF and how it maps to 3GPP network slice management.  In

Are these references to figures in 28.801? I don't see Figures 2(A) and
2(B) in this document even if Figure 2 seems to be about this topic.

---

Figure 2

Note: Refer to Figure-1 for S-NSSAI 01111111, AN, CN and IETF networks
slices 4,6 and 1

I think this should be

Note: Refer to Figure-1 for S-NSSAI 01111111, AN, CN and, IETF networks
slices 4, 1, and 6

---

Figure 2 is too wide.

You can fix this as:

                   +-----------------+
                   |       NSMF      |
                   +-----------------+
        +----------|     S-NSSAI     |----------+
        |          |(e.g. 011111111) |          |
        |          +-----------------+          |
        |                   |                   |
        V                   V                   V
 +-------------+ +---------------------+ +-------------+
 |  AN NSSMF   | |       IETF NSC      | |   CN NSSMF  |
 +-------------+ +---------------------+ +-------------+
 |   AN Slice  | | IETF Network Slice  | |   CN Slice  |
 | Identifier  | |     Identifier      | |  Identifier |
 | (e.g., 4)   | |     (e.g., 6)       | |  (e.g., 1)  |    Management
 +-------------+ +---------------------+ +-------------+      Plane
      |           |                   |           |      -------------
      |           |                   |           |
      V           V                   V           V      -------------
      /\       +-----+             +-----+    +-------+        Data
     /AN\ -----|  PE |-----...-----| PE  |----|  CN   |        Plane
    /____\     +-----+             +-----+    +-------+

Note: Refer to Figure-1 for S-NSSAI 01111111, AN, CN, and IETF networks
      slices 4, 1, and 6

---

4.

s/The following figure/Figure 3/
s/mapping end/mapping an end/
s/in management/in the management/
s/data(user)/data (user)/
s/Information(S-NSSAI)/Information (S-NSSAI)/
s/Neetwork/Network/
s/draft/document/

---

Figure 3 and 5.1

The slicing framework is now using "IETF Network Slice Service
Interface" and "Network Configuration Interface" in place of "NSC NBI"
and "NSC SBI".


(Search for "NBI", "SBI", "northbound".)

---

4.

OLD
   The relationship between these identifiers are specifies in the
   following sections.
NEW
   The relationships between these identifiers are specified in the
   following sections.
END

---

Section 5

I would love to see these steps on a figure. I think steps 1-8 might
look like the following, but I don't know how to put 9-12 on a figure
because this is the first mention of this work (not even sure which
components would be involved).

                   +-----------------+
                   |       CSMF      |
                   +-----------------+
                            | 1
                            V
                   +-----------------+
                   |    NSMF 2,3,8   |
        +----------|      S-NSSAI    |----------+
      4 |          +-----------------+          | 5
        |                   | 6                 |
        V                   V                   V
 +-------------+ +---------------------+ +-------------+
 |  AN NSSMF   | |       IETF NSC      | |   CN NSSMF  |
 +-------------+ +---------------------+ +-------------+
      |           |         |         |           |
      |           |         | 7       |           |
      V           V         V         V           V
      /\       +-----+             +-----+    +-------+
     /AN\ -----|  PE |-----...-----| PE  |----|  CN   |
    /____\     +-----+             +-----+    +-------+

---

Section 5.1

s/management Plane/management plane/
s/Service Profile defined in[TS28541]/The Service Profile defined in
[TS28541]/

---

5.1

OLD
   GSMA(Global System for Mobile
   Communications Association) defines the [GST] to indicate the network
   slice requirement from the view of service provider.
NEW
   The Global System for Mobile Communications Association (GSMA)
   defines the Generic Network Slice Template (GST) in [GST] to indicate
   the network slice requirement from the view of the service provider.
END

---

5.1

s/analysis/analyses/
s/categorize/categorizes/
s/finished If/finished.  If/
s/is supposed to/needs to/
s/draft)/document)./

---

5.2

s/draft/document/

---

5.2

   Editor's note: The mapping relationship between NSI defined in
   [TS23501] and S-NSSAI defined in [TS23501] is still in discussion.

I don't know what to make of this note. It is surely not something the
IETF needs to resolve, and I assume the discussion is going on in 3GPP.
Yes, as you state in the previous paragraph, there is an assumption
about the existence of the mapping relationship, but isn't the actual
relationship out of scope?

---

5.3

OLD
   If multiple network slices are carried through one physical interface
   between AN/CN and TN, IETF Network Slice Interworking ID in the data
   plane needs to be introduced.
NEW
   If multiple network slices are carried through one physical interface
   between AN/CN and TN, an IETF Network Slice Interworking ID needs to
   be introduced in the data plane.
END

BUT!
This section needs to explain why this is a requirement, and a what
point in the network it is required.

Section 4 gives a bit of explanation about the use of the IETF Network
Slice Interworking Identifier. That implies that it is used in the data
plane to indicate onto which IETF network slice a particular e2e packet
should be mapped. In other words, it enables demux of traffic on a
single channel (we may say access connection) into different IETF
slices.  As you note in Section 4, there are obviously many possible
ways of doing this already (depending on the AC encoding).

And you go on (in 5.3) to say:

   If different network slices are
   transported through different physical interfaces, Network Slices
   could be distinguished by the interface directly.  Thus IETF Network
   Slice Interworking ID is not the only option for network slice
   mapping, while it may help in introducing new network slices.

Can I suggest that the "IETF Network Slice Interworking ID" is a logical
concept that is needed in all cases. In some cases it is encoded in the
physical interface ID, in others it is encoded in the virtual interface
or channel ID (such as VLAN tagging), or it may be achieved using IP or
UDP information.  However, in the absence of all of these, a new piece
of information will need to be encoded in the packet.

---

5.3.1

s/a uplink/an uplink/

---

5.3.1

I suggest you turn the Editor's Note into a new section as follows:

5.3.1.1 3GPP Network Instance

   [TS23501] defines the concept of a "Network Instance" that is used to
   indicate the TN instance intended to support an end-to-end slice.
   The Network Instance could be determined from the S-NSSAI, and it
   could also depends on other information.

   However, the concept of Network Instance is neither a necessary nor
   sufficient condition for identifying an IETF network slice.  That is,
   multiple IETF network slices may be supported within the context of a
   single network instance meaning that the Network Instance identifier
   is not sufficient to identify the IETF network slice.  Furthermore,
   an IETF network slice may be supported by more than one underlay
   network (in parallel or in series) meaning that the Network Instance
   identifier may not provide adequate indication of how the IETF
   network slice is formed or identified.

---

5.3.2

You need to explain "UE", "NS", and "UPF".

The figures need numbers and captions.

There seems to be some imbalance in the first figure between "(R)AN"
which is a network, and "UPF" which is a function.

I think you can just convert the Editor's Note into text.

---

5.3.2 and subsections

I found the 2nd and 3rd figures in 5.3.2 somewhat unnecessary. They are
interesting, but they don't serve any purpose in the mapping discussion,
I think.

Furthermore, while the subsections are perfectly correct, they seem to
be pointing to some of the options. I wonder whether they are really
necessary. Couldn't they be replace with a simple statement that the
fields of the UDP, IP, Ethernet encapsulation headers could be used
(where they are visible to the TN) to carry the IETF Network Slice
Interworking ID."

---

6.

The figure needs a number and a caption. It's a nice figure, but it
could use a few sentences to describe what it is showing.

---

7.

The "TBD" can be replaced with "This document makes no requests for
IANA action."

---

8.

You should be able to come up with some discussion of security. Does
the security of the e2e slice depend upon the security of the TN slice?
Is it possible to attack the TN by messing with the various identifiers
passed to it? Is it possible to attack user traffic by steering it to
the wrong TN slice? Who is responsible for resolving these issues
(specification writers, implementers, operators)?

---

9.  Contributors

   The authors would like to thank the contributors for reviewing the
   draft and giving valuable comments:

Are these Contributors or is this the Acknowledgements Section?

---

10.

[I-D.ietf-teas-ietf-network-slice-definition] is dead. You don't
reference it so you can remove it from this section.