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

[Adrian Farrel <[e-mail]>]

Hi Oscar, all,

I’ve read this draft as part of the adoption poll, and I attach some
comments. My current view is that, while the topic covered by the title of
the draft is important and should be worked on within the working group,
this document is not ready for adoption. I set out my reasons below, and
also provide some detailed review comments: most of the detailed minor
comments and nits could wait until after adoption, but the major issues form
part of my reservations about adopting the current revision.

Thanks,
Adrian

===

My take-away from this document is that it does three things:
- Describes 5G end-to-end network slices and their component parts
- Describes the general mapping and connections when 5G slices utilise IETF
transport slices
- Talks about specifics of using existing IP/MPLS (and SR) techniques to
realise IETF transport slices and stitch them into e2e slices

I think a good chunk of the description of 5G slices has been moved to
Appendix B, but there is still a lot of text in the document explaining 5G
slices. I’m wary of us “interpreting” 3gpp specifications and technologies.
I think all of that material does not belong in an IETF document (even an
appendix of an informational one). If the 3gpp documents are lacking then
the place to fix them is in that body, but if they are not deficient then we
can just reference them and move on.

It seems to me that the general mapping discussion is applicable to any IETF
technology (present or future). We already have a draft that we have just
finished polling for adoption (draft-gcdrb-teas-5g-network-slice-application
with some of the same authors) that covers much of the common ground about
the general mapping. It would be good to contain that material in a single
document, and I would suggest working to move the relevant material to
draft-gcdrb-teas-5g-network-slice-application. That is not to detract from
the text in this document that describes the general mapping, just to say we
don’t need it in two places.

The discussion of using existing IP/MPLS technology to provide support for
end-to-end 5G slicing (sections 4 and 7) is practical and would make a
useful document.


However, if/when this draft is adopted, can we please sort out a couple of
things before the -00 version of the WG draft is posted?

1. I am having a hard time believing that the people named on the front page
wrote considerable parts of the text. Are they really all co-authors? Are
they even Contributors? Let’s please get out of the habit of “signing up to
show our support” – it’s a poor idea that devalues the work and damages the
reputation of the people named. And, anyway, could the chairs please make it
easy for us to know who is holding the pen as the draft moves forward
(presumably Krzysztof and Richard?).

2. Embedding SVG figures is, of course, allowed. But was it really
necessary? I’m pretty sure all of your figures are only SVG versions of
ASCII art, anyway. (Why do I care? Can’t be read by an ASCII editor. Makes
for nonsense XML.) 

==Questions==

3.1 has (my emphasis)

      The objective of 5G Network Slicing is to provide *dedicated*
      resources of the whole 5G infrastructure to some users/customers,
      applications, or Public Land Mobile Networks (PLMNs) (e.g., RAN
      sharing).  These resources are from the Transport Network (TN),
      RAN, and Core Network Functions and the underlying infrastructure.
You immediately go on to say (of the NSS)

      [TS-28.530] defines 5G Network Slicing by introducing the concept
      of Network Slice Subnet (NSS) to represent slices within each of
      these domains: RAN, CN, and TN (i.e., RAN NSS, CN NSS, and TN
      NSS).  As per 3GPP specifications, an NSS can be shared or
      dedicated to a single slice.
So, are the resources dedicated or can they be shared? At the least, one of
these paragraphs is unclear.

==Major==

3.2.1

There seems to be some disagreement between your definitions of TN Segment
and Local Segment. If the TN Segment provides connectivity between two sites
that host NFs, then the possibility of a Local Segment that connects an NF
to the TN seems strange. It is only with your later definition of a site
(and having had a conversation with Krzysztof) that this becomes a little
clearer to me. (BTW in Figure 2 you have “5G site” not “site” making it
appear that there are two different things.)

I think the problem stems from the text in 3.2 where you describe what 3gpp
means by TN, and then say “but when we say TN we mean only that bit of the
TN controlled by the TN operator.” I think this is why you go on to talk
about segments in 3.2.1, and perhaps if in 3.2 you had 

   This document defines the Transport Network Segment (see Section 
   3.2.1) as that part of the TN slice with a service provider scope.  
   That is, the TN Segment extends up to the PE, or the CE if it is also 
   managed by the service provider.  The TN Segment may be combined with
   other segments (Local Segments) to achieve NF-to-NF TN slices.

To complement this, Figure 1 might usefully show the whole, composed, TN
slice. (Noting that Figure 1 falls into the trap of showing the “Transport
Network” as something different to that described by 3gpp. You may mean the
“service provider’s network.”

This last point is also found in the subsequent paragraph:
.  In such a case, there is no TN Segment (i.e., no
   Transport Network Node is present in the datapath).
I think, per 3gpp, there may be transport network nodes, but they are not
service provider nodes.

For what it is worth, you may find the composed network slice draft useful
both for terminology and as a reference to help explain composing an
end-to-end slice from multiple slice segments.

--

Section 5 seems a lot. It’s not my area of expertise, but it seems like a
very large amount of material to describe how to map a RAN slice to a
transport slice.

==Minor==

Section 2

   Edge Transport Node (ETN):  Node, under the transport domain
      orchestration, that stitches the transport domain to an adjacent
      domain (e.g., enterprise network, data center, peer provider
      network).  An ETN can be be a Provider Edge (PE) or a managed
      Customer Equipment (CE).
When you say “under transport domain orchestration” I guess you mean “wholly
or partially”. That would allow for a number of other scenarios including a
slice that terminates at an SDP within a CE, but where the whole CE is not
under management control of the transport network operator. I suspect there
are also cases where the SDP is in the CE and the CE is not managed in any
part by the transport operator. 

Reading further, in 3.2.1, I wondered by you needed to introduce the term
ETN. Of course, you are welcome to, but does it help? You say the ETN is the
node that stiches together the Local Segments and TN Segments. You further
note that depending on the design, the placement of the SDP may or may not
be enforced on the ETN itself. I don’t see how that has meaning! The slice
goes as far as the SDP, so if you want to stich the slice to something else,
you must do it at the SDP. Thus, in your terminology, the ETN must contain
the SDP. (This is why I don’t think the ETN is a useful term, and you should
just talk about stitching at the SDP. You may want to limit your realisation
to specific placements of the SDP, and that would be fine.)

--

3.2
   Additionally, we assume that the
   Transport Network is IP, MPLS, or SRv6 capable.
This is OK, but you need to square it with the document title and say it in
the Abstract and Introduction.

--

3.2.1

You say...
   We consider
   Local Segments as an extension of the connectivity of the RAN/CN
   domain without slice-specific performances requirements by assuming
   that the local infrastructure is overprovisioned and implements
   traditional QoS/Scheduling logic.
Why do you do this? I understand that, in this document, you do not want to
consider slicing in the site network. And I can see how that is not relevant
to your deployments. But there are several problems with your considerations
and assumptions that rule out many deployments based on the TN segment
realisation you describe. Not least of these is the case where the site is
not part of the RAN or CN but supports access to the NFs. Why don’t you just
put “the management and deployment of local segments is out of scope of this
document.”

--

Figure 3 has a number of cases with a PE, but no CE. Feels a bit odd.

--

3.2.2

   Figure 4 is a basic example of a Layer 3 CE-PE link realization with
   shared network resources, such as VLAN-ID and IP prefixes, which must
   be passed between Orchestrators via the Network Slice Service
   Interface ([I-D.ietf-teas-ietf-network-slice-nbi-yang]) or an
   Attachement Circuit Service Interface
   ([I-D.boro-opsawg-teas-attachment-circuit]).
I suggest s/must be/can be/ and s/via/via a configuration such as/

Otherwise your “must” makes the two references normative.

--

3.4

Is this section assuming that the transport network only supports one 5G
provider? That is, in stating that the eMBB slice is global and first, and
that subsequent slices share the CP, there is an implicit assumption that
there will not be other RANs supported by the same TN, but using other eMBB
slices.

The text…
   At the time of writing (2023), Section 6.2 of [NG.113] specifies that
   the eMBB slice (SST=1 and no SD) should be supported globally.  This
   5G slice would be the first slice in any 5G deployment.
…is, perhaps, a little vague: “at the time of writing”, “should”, “would
be”.

--

4.

   5G functions can expose the 5G slices to the transport
   Domain
It’s not clear to me why the transport Domain needs to know about the
identities of 5G slices. I think it is possible that there is a point in the
system that is responsible for aggregation/multiplexing/mapping from 5G
slice to transport slice, but it isn’t clear to me that this point is *in*
the transport domain. Can you clarify the text to explain what this is all
about.

--

4.1

   However, SDPs for a same slice at
   different locations may also use different VLAN values.  Therefore, a
   VLAN to IETF Network Slice mapping table MUST be maintained for each
   AC, and the VLAN allocation MUST be coordinated between TN
   orchestration and local segment orchestration.

I think you can replace “MUST be” with “is” in both cases.

--

4.2

   Note that this addressing scheme is local to a node; intermediary
   nodes are not required to associate any additional semantic with IPv6
   address.

   One benefit of embedding the S-NSSAI in the IPv6 address is providing
   a very easy way of identifying the packet as belonging to given
   S-NSSAI at any place in the transport domain.  This might be used,
   for example, to selectively enable per S-NSSAI monitoring, or any
   other per S-NSSAI handling, if required.
In the first paragraph you say that intermediary nodes are not required to
understand the IP address semantic, while in the second paragraph you give
an example of understanding the IP address semantic at transit nodes.

Further, if the addressing scheme is local to a node, it would be used at
the ingress to the transport network and could help with packets flowing in
the opposite direction. But isn’t the knowledge also needed at the egress
from the transport network?

(I’m not a fan of encoding additional semantics into IP addresses. It is, of
course, a viable engineering solution – it just feels dirty. Mapping tables
are just so much nicer.)

--

4.3.2

   MPLS labels are allocated dynamically, especially in Option 10B
   Deployments

“especially” is a bit weird in this context. If labels are allocated
dynamically, then there is no special case.

--

Option 10C in 4.3.3 looks quite interesting. Hope to see some text here.

--

6.

   This document refers to such tunnel groups as
   'transport planes'

This might not be the wisest redefinition of the term “transport plane”.
https://www.itu.int/ITU-T/studygroups/_COM15/otn/transport.html
https://www.slideserve.com/aretha/transport-plane
https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20knowlege%20plane%2
0for%20the%20internet.pdf

Anyway, what is the difference between a transport plane, an NRP, and a
filtered topology? It would be helpful to put the transport plane in the
context of draft-ietf-teas-ietf-network-slices.

I know you are architecting with a single NRP, but that leaves you no way to
partition any further. Hence, I think, your “collection of tunnels”. Seems
broken to me.

--

7.

   For its decision-making, the SMO needs
   information from the NSC about the observed latency between DCs.
   Preferably, the NSC would present the topology in an abstracted form,
   consisting of point-to-point abstracted links between pairs of DCs
   and associated latency and optionally delay variation and link loss
   values.

This is an interesting conjunction of the function offered by ALTO (to
determine which end points to connect to) and the IETF network slice
service. Not sure it is the NSC’s responsibility to report the network
capabilities to the SMO, but *some* component in the transport network needs
to do this. An alternative would be a PCE or direct reporting from the
network using (say) BGP-LS.

--

9. 

I hope you can find some more words for the security considerations.

==Nits==

Section 1 para 1
Why “high-level”? Suggest to delete it.

--

Section 1

   each realization might be optimized for the different
   network slicing use cases that are listed in
   [I-D.ietf-teas-ietf-network-slices]

I don’t think the framework is very normative in its brief list of use cases
provided in its first introductory paragraph. Your text would be better as:

   each realization might be optimized for different
   network slicing use cases.

--

Section 1

   This document describes a basic - using only single NRP - IETF
   Network Slice realization model in IP/MPLS networks, with a focus on
   fulfilling 5G slicing connectivity requirements.

Can we fix the readability?

   This document describes an IETF Network Slice realization model
   in IP/MPLS networks, using a single NRP and with a focus on
   fulfilling 5G slicing connectivity requirements.

--

Section 1

   The reader may refer to [I-D.ietf-teas-ns-ip-mpls] for more advanced
   realization models.
Let’s not go there. You’re not going to successfully list every alternative
realization draft, so don’t list any.

--

Section 1

   The reader may refer to [RFC6459] and [TS-23.501] for
   more details about 3GPP network architectures.
It’s true, but. The reader of this document is possibly interested in 5G
network architectures, and 6459 does not discuss them. I think the reference
from the Appendix is fine, but not here.

--

2.

I was surprised to find BCP14 language used in this Informational draft. Are
you telling us what we must do, or are you describing a realization?

I’ll try to spot and call out each use as I come across it.

--

2.

s/be be/be/

--

3.1

s/whithout/without/

--

3.1

      TN Slicing is implemented using IETF technologies, therefore,
      inline with [I-D.ietf-teas-ietf-network-slices].
I think that IETF technologies are probably only used to implement IETF
network slicing. So perhaps, “TE slicing implemented using IETF technologies
is described in [I-D.ietf-teas-ietf-network-slices].”

-- 

3.1

      In this document, the term "IETF Network Slice" (IETF NS, or INS
      in short) is used to describe the slice in the Transport Network
      domain of the overall 5G architecture, composed from RAN, TN, and
      CN domains.
It might be helpful to prefix this with…

      Although IETF Network Slices can be use more generally,

--

3.2 needs a citation for “The 3GPP specifications”

--

Figure 1 could usefully show SDPs

--

Figure 2 needs to be referenced from the text. Possibly the previous
paragraph?

--

In Figure 3, I think some of the SDPs are supposed to be inside the nodes?

--

3.2.1

s/simplicification/simplification/

--

3.2.2

s/dataplane/data plane/
s/Attachement/Attachment/

--

3.3

Decide on “EMBB” or “eMBB” and add it to the appendix

--

4. 

s/discrimantion/discrimination/

--

4.

      In the managed CE use cases (use cases A1, A2, B1, and B2 depicted
      in Figure 7)

I think you may mean Figure 3.

--

OLD
Figure 8: Resource Allocation in with single NRP Slicing Model
NEW
Figure 8: Resource Allocation Slicing Model with a single NRP
END

--

Figures 8, 9, and 10 need to be referenced from the text.

--

4.

   The S-NSSAI is not visible to the transport domain,
   so instead 5G functions can expose the 5G slices to the transport
   domain by mapping to explicit L2/L3 identifiers such as VLAN-ID, IP
   addresses, or Differentiated Services Code Point (DSCP) as documented
   in [I-D.gcdrb-teas-5g-network-slice-application].

It is unclear whether the citation here is for all the mappings described or
just DSCP. Depending on your intent, you can fix this as:

   The S-NSSAI is not visible to the transport domain,
   so instead 5G functions can expose the 5G slices to the transport
   domain by mapping to explicit L2/L3 identifiers [I-D.gcdrb-teas-5g-
   network-slice-application], such as VLAN-ID, IP addresses, or 
   Differentiated Services Code Point (DSCP) as documented in.

Or

   The S-NSSAI is not visible to the transport domain,
   so instead 5G functions can expose the 5G slices to the transport
   domain by mapping to explicit L2/L3 identifiers such as Differentiated 
   Services Code Point (DSCP) as documented in [I-D.gcdrb-teas-5g-
   network-slice-application], VLAN-ID, or IP addresses.

--

4.1

   represented at the SDP
   by a VLAN, or double VLANs (commonly known as QinQ)

“Represented by a VLAN” or “represented by a VLAN ID”?

--

4.1

   Each VLAN can represent

I think that this section s describing a mechanism that is used. So you
would use “Each VLAN represents”

--

4.3

I see that option 10A described in 4.3.1 does not use MPLS label hand-off.
Doesn’t that mean that the title of section 4.3 is a bit misleading?

Maybe retitle it in some way?

--

6.

s/readibility/readability/

--


From: Teas <[e-mail]> On Behalf Of Oscar González de Dios
Sent: 03 April 2023 01:56
To: 'TEAS WG' <[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