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

["Ogaki, Kenichi" <[e-mail]>]

Hi Xuesong, Adrian and authors,

To correctly understand how 3GPP models their slice architecture is important for how to map 3GPP slice and IETF network slice.

The following comments mainly focus alignments with the current 3GPP Rel.17 specification,  especially modeling aspects. Authors' solution proposal how to map should change where the assumption changes, then I haven't touched on the proposal.

If authors try to merge with two other related drafts as chairs suggested, could you also consider to?


-Section 1
What's the definition of performance in "performance commitment"? 3GPP slice also requires not only, what we call, performance, but SLS(Service Level Specification) like SLO/SLE, as already referring TS28.541 clause 6.3.3, ServiceProfile, and GSMA NG.116 clause 3, GST.

How does this draft differentiate "The procedure for lifecycle of an end-to-end network slice instance" and "End-to-end network slicing provisioning"? If authors want to touch on two different syntax from two SDOs as the same semantic, it's better to reconsider how to explain that.


>But there is *no* specifications about how to map end-to-end network slice to IETF network slices in Transport Network (TN).

It may be a matter of degree and depends on the objective, but 3GPP defines there transport endpoint of AN/CN network slice subnet with the facing TN endpoint and QoS profile as EP_Transport in TS28.541 clause 6.3.18, as draft-contreras-teas-3gpp-ietf-slice-mapping explains.


-Section 3
S-NSSAI is "Single Network *Slice Selection Assistance* Information", not 3GPP slice identifier.
TS23.531 defines "Network Slice Instance Identifier(NSI ID)" and the clause 5.15.5.2.1(B) defines "The NSSF may return NSI ID(s) to be associated to the Network Slice instance(s) corresponding to certain S-NSSAIs." as a C-Plane sequence, for example.
As M-Plane information model, TS28.541 clause 6 defines S-NSSAI as one of ServiceProfile, SLS, attributes which is mapped to NSI. See TS28.541 clause 6.2.1, 6.3.3.2 and serviceProfile.pLMNInfoList in 6.4.1.
Actually, the above "NSI ID" defined in TS23.501 corresponds to that of CN network slice subnet instance(NSSI) in TS28.541.

-Section 5
Step 3
From "the procedure for lifecycle of an end-to-end network slice instance" defined in TS28.531 clause 5.1.1, NSMF *doesn't* identify the network function and the required resources. That's NSSMF's functionality. Also, NSMF *doesn't* assign S-NSSAI as wrote above.

Step 11
What kind of the solution does authors suppose to encapsulate slice　ID into a packet?

-Section 5.1
3GPP doesn't use the term "TN NSSMF", but "TN Manager". See TS28.531 Clause 5.1.1, for example.

TN domain specification is out of scope of 3GPP, then 3GPP itself doesn't use the terms "TN NSSI" and "TN Network Slice Profile".


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

As above wrote, TS23.501 clauses 5.15.5.2.1(B) and 5.15.5.3 defines how S-NSSAI to be mapped to NSI in CN scope. The mapping information is stored on NRF(Network Repository Function) as "NF profile" as defined in clause 6.2.6.2.

-Section 5.3.1
Where in TS23.501 defines "Network Instance"?

-Section 5.3.2
In a transport slice discussion, we rarely see N6(UPF rear) interface discussion. This is connected to the internet or LxVPN, and usually through Gi-LAN, a kind of SFC.
TS28.541 clause 6.3.32 defines n6protection which requires such functionality.

If TN NS within AN NS and CN NS is avoided as "Editor's note", why N9 interface is depicted in the following figure?

-Section 5.3.2.1
If invisible means IPSec encapsulation to N3 interface, for example, authors describe so.


All the best,
Kenichi


-----Original Message-----
From: Teas <[e-mail]> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Thursday, May 26, 2022 4:56 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [Teas] Review of draft-geng-teas-network-slice-mapping

Hi Adrian

 

Thanks a lot for reviewing the document. All the nits will be addressed in the next version, and please find some further response inline.

 

Best

Xuesong

 

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Monday, May 23, 2022 8:39 PM
To: [e-mail]
Cc: [e-mail]
Subject: 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.

 

[Xuesong] Agree that the terminology could be specified as "5G transport network slice". As you have mentioned, 5G is one of the most important use case for IETF network slice, at the same time the motivation of this document is also to provide the mapping process for IETF Network Slices and 3GPP Network Slices. So maybe we could consider to modify the title but remain the word ・/span>mapping・/span> to show the basic idea, also includes the applicability.

---

 

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.

 

[Xuesong] Sure, thanks for pointing this out.

---

 

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.

 

[Xuesong] OK. I think ・/span>Transport Network・/span> is more suitable in the document, comparing to other concept as RAN and CN.

 

---

 

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.

 

[Xuesong] OK. I think ・/span>IETF Network Slices・/span> is fine to align with the framework draft.

 

---

 

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.

 

[Xuesong] Sure. We could add more explanations here.

 

---

 

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.

 

[Xuesong] Sorry the figure number here is not consistent with the description. We will update it in the next version.

 

---

 

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

 

[Xuesong] You are right. We will the change the order in the next version.

 

---

 

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 

 

[Xuesong] Thanks! We will modify the figure accordingly.

 

---

 

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".)

 

[Xuesong] OK, we will syn with the framework document.

 

---

 

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   | 

    /____\     +-----+             +-----+    +-------+

 

[Xuesong] Thanks. We will check how to add the step number into the figure.

 

---

 

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?

 

[Xuesong] Yes, the actual relationship is not in the scope of IETF. We will remove this note.

 

---

 

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.

 

[Xuesong] Yes, you are right. "IETF Network Slice Interworking ID" is a logical concept. Physical Interface ID could also be considered as IETF Network Slice Interworking ID. We will update the description here.

 

---

 

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.

 

[Xuesong] Sure

 

---

 

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.

 

[Xuesong] OK, for example we can update UPF to CN

 

 

---

 

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."

 

[Xuesong] This is a good suggestion and the figures and subsections are here for the IETF people who may be not familiar with the encapsulation defined in 3GPP and confused about the relationship between the ・/span>IETF Network Slice Interworking ID・/span> and the existing 3GPP encapsulation. If it is not so necessary, we could consider to compress this part.

 

---

 

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.

 

[Xuesong] Sure, we could add more explanations here.

 

---

 

7.

 

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

 

[Xuesong] OK

 

---

 

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)?

 

[Xuesong] Good suggestion. We will add some contents here.

 

---

 

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?

 

[Xuesong] This is a contributor section and there may be an Acknowledgements Section in the future.

 

---

 

10.

 

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

 

[Xuesong] OK