Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

["Dongjie (Jimmy)" <[e-mail]>]

Hi Oscar and authors,

Sorry for the late response to this adoption poll. I've finished my reading of this document (initially based on the -06 version, then a double check on the -07/08 version), please find some comments as below. It would be good if those comments could be considered before this document is adopted.


- The title of the draft

The title says it describes "a realization of IETF network slices", but the content is not just about the realization of IETF network slice itself, it also has large amount of content related to the 5G network slice and QoS mapping to IETF network slices. Maybe the title could be modified to reflect the content better.


- The Introduction

It says this document provides an IETF network slice realization model with "a focus on fulfilling the 5G slicing connectivity requirements". Does this mean the SLO and SLE requirements are not the focus of this model/document? Suggest to clarify what the connectivity requirements means in this document.


- Conventions and Definitions

Some of the terms are different from those used in IETF, such as SMO, ETN.  I found ETN is removed in version -08, and SMO is now moved into the appendix, but it is never used in the main text, so maybe SMO can also be removed.




- Section 3.1 provides a picture about the scope of Transport network vs RAN and CN, while in the picture it is not clear where the NFs of RAN and CN reside in. Should they also be part of the DC or the public cloud? And TN only provides the connectivity in the DC and cloud.


- Section 3.2 mentions "TN Slicing provides various degrees of sharing of resources between slices". Is this essentially the same as "various degrees of isolation"?



- Section 3.2 gives an example of TN slice resource management:

      "For example, shared TN resources could be provided in the backhaul, and dedicated TN resources could be provided in the midhaul."


     Suggest to provide some reasoning why TN resources can be shared in the backhaul, while dedicated resource is needed in the midhaul.


- Section 3.3.1, It is not clear what is the purpose of this subsection, does the single or distributed PE or CE model have different impact to the IETF network slice realization? If so, maybe it is better to be elaborated.


- Section 3.3.2, it is a little bit confusing to use inter-AS option B/C to model the AC between CE and PE, as it was used between PEs or ASBRs.  And the interpretation of ASBR and PE in inter-AS option C as an example of "distributed PE" is something unusual for an IETF document. There may be deployments using such mechanisms, while the description may cause confusion in IETF.


- Section 3.4.1, it is not clear to me whether the TN slice in the customer site is out of the scope of IETF network slice, if it uses IETF technologies for slice instantiation.


- Section 3.6. This section describes the first and the subsequent 5G network slices, For this document it may also need to describe the implications to the realization of IETF network slices. The figure shows some mapping examples, while some text would be helpful.


- Section 4.1, 4.2 and 4.3.  The text in these subsections are more about the interworking and mapping (it is called hand-off in the draft) between 5G slices and IETF network slice, thus is not quite relevant to the title and the beginning of section 4 (overview of the realization model). This also has some overlap with section 7 of the 5G end-to-end slice applications draft.


- Section 4.2. If S-NSSAI is encoded in the IPv6 addresses of NFs, since transport network is not aware of the S-NSSAIs, some mapping table for IP addresses to IETF network slice mapping would be needed on the PEs for mapping 5G network slices to IETF network slices correctly. Note that the mapping between 5G slices to IETF slices is not always 1:1.


- Section 4.3. This section could simply describe the use of MPLS label as the data identifier for mapping 5G slices to IETF network slices. Not sure the details about how the MPLS label and route targets are distributed in BGP control plane are really needed. IMO a reference to RFC 4364 would be good enough.


- Section 5. If my understanding is correct, this section is mainly about the mapping of 5G QoS parameters to TN QoS parameters at the TN edge nodes (the PE). Then it is better to rename section 5.3 to "Realization of QoS Mapping Models".


- Section 5.4.1 I'm not sure the details about the rate limiter mechanism are needed, perhaps reference to existing QoS RFCs would be suffice.


-  Section 5.4.2. It seems contradicting that the beginning of section 5.4 says:

    "QoS enforcement on transit links is fully coarse (single NRP, sharing resources among all IETF Network Slices)"

    While section 5.4.2 says for some use cases "fine-grained resource control to guarantee at least CIR for each slice is required."




- Section 5.6. Some text may be needed to explain why per-slice outbound resource control is needed on the edge nodes, while on the transit nodes only traffic-class based PHB is needed. For example, is there possibility of outbound direction congestion on the transit nodes due to the use cases described in section 5.4.2?


- Section 6. Similar comments as Adrian's, the relationship between transport plane and NRP needs to be clarified. In this document do you want to make it explicit that the transport planes are in the same NRP, thus share the same set of network resources? In that case they are just different set of transport paths with no per-plane resource reservation.

   And in section 6.1 and 6.2 it seems it is more about the mapping from QoS Class to transport planes, rather than the mapping from slices to transport planes.  This needs to be clarified in figure 28.  Actually figure 29 is correct in the content, while the title is a little bit misleading.


- Section 7.2.1. It is not clear how SPF is related to bandwidth management?  The example in this section is to use latency metric for SPF or Flex-Algo path computation.


Best regards,
Jie

From: Teas [mailto:[e-mail]] On Behalf Of Oscar González de Dios
Sent: Monday, April 3, 2023 8:56 AM
To: 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

Dear TEAS WG colleagues,

This email begins a 2-week adoption poll for:

https://datatracker.ietf.org/doc/draft-srld-teas-5g-slicing/

There is no IPR disclosed for this document. All authors and contributors have replied to the IPR poll.

Please voice your support or objections to adoption on the list by the end of the day (any time zone) April  17th.

Thank you,

  Oscar (as Co-chair)


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição