Re: [Teas] Review of draft-ietf-teas-5g-ns-ip-mpls

[Richard Roberts <[e-mail]>]

Hi daniele,

Thanks a lot for your feedback. Find my answers inline.

Regards,
Richard




Juniper Business Use Only
From: Teas <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, December 1, 2023 3:30 PM
To: 'TEAS WG' <[e-mail]>
Subject: [Teas] Review of draft-ietf-teas-5g-ns-ip-mpls

[External Email. Be cautious of content]

Authors, WG,

I reviewed draft-ietf-teas-5g-ns-ip-mpls. Please find below some comments:


  *   General: This is applicable in general to all the network slicing drafts: I don’t really like the usage of “RFC XXXX Network Slice”. The term will need to be used both in IETF and mostly outside the IETF, it needs to be more intuitive. I’m happy with TN network slice, IETF network slice, but not RFC XXXX, it doesn’t provide context for an external user. The term Transport Network is controversial due to different meaning, but the in the draft is extensively used, then why not using it also to identify the slice? Moreover, if one day the RFC will be obsoleted? We’ll need to update the name of the network slices?


[RR] I find RFCXXX a bit unpractical too but that’s not our call 😊. I also share the that the TN is controversial, and this is why we introduced a section to define and describe the scope of the TN for this document  (3.1). Based on this definition, the semantic is extended to orchestration domains and slices: TN domain and TN slice (so yes “TN slice” is used with and end-to-end datapath unlike the the RFC XXX slice, which more provider network focused). The overall idea is map with the key 5G orchestration domains involved in the realization of a slice: RAN, CN and TN. The link with orchestration is actually important to us, especially intent-based realization of TN slices (i.e. acaas and slice-nbi yang DM).



  *   Abstract: s/This feature covers slicing requirements/This feature introduces new requirements for all the domains.
  *   Introduction: “(NRP), which is simply a collection of   resources identified in the underlay network” – which underlay network? Underlay WRT to the NRP? It needs to be explained a bit better.
  *   Introduction:  “This document describes an RFC XXXX Network Slice realization model in IP/MPLS networks, using a single NRP and with a focus on fulfilling 5G slicing connectivity requirement” – Unsing a single NRP is a choice of the authors or there is a 1:1 mapping between Slice and NRP?

[RR] NRP is one example of realization, this is not a strict 1:1 mapping.


  *   Section 3.3 and related: The definition of transport network scope and reference design is very useful, but would have been more appropriate in the framework (too late now…). Why does the transport network go from NF to NF and not from CE to CE? Isn’t the NF typically part of the RAN or the PC domains? ¨

[RR] If you take things from 3GPP orchestration perspective the RAN/CN domains stops once the packet leaves the NF. Think of these 3GPP N2/N3, N6, F1,… interfaces and consider these as transported over the TN (i.e. How packets are transported between NF is TN black magic). This definition maps with these domains (see first point: orchestration alignment). Then we worked at modelling and decomposing the TN (still thinking on orchestration) so we can focus on the management of each individual TN sub-domains as well as the stitching between these (i.e. taking the example of ORAN: the customer site maps with the OCloud site ORAN defined in WG6 and while the Provider Network management is defined in wg9…).  I know that in practice the word TN is overloaded (but which term in this industry isn’t ?)– this is why a strict definition with E2E scope is provided at first.


  *   Customer site orchestration domain: is this aligned with the framework? From the framework I understood that the NSC manages the RFCXXXX network slice, but here the orchestraion of the TN is done by the RFCXXXX + customer site orchestrators. Does this mean that the TN slice and the RFC XXXX slice are different things? In this case it should be stated clearly before in the text (maybe it is but it took me 12 pages to understand it?) Maybe anticipating figure 5 to the beginning as clearly defining the scope of RFC XXX slice and TN slice helps. I went back to check the framework and couldn’t find any relationship between the RFC XXXX network slice and the TN network slice, shouldn’t it be there?

[RR] Yes it is aligned, we had many discussion with framework folks. The TN slice is end to end, while the RFCXXX is defined between PEs and/or CEs depending on sdp placements. Section 4.2 decomposes the TN slice in multiple segments. It is explicitly mentioned that the provider network segment maps with an RFCXXX slice realized by the NSC. I know this is a quite a long story to get there,  and we can highlight this more clearly so I hear the point that we should be more explicit to ease the readers understanding. So  now that you understood that TN slice = E2E (NF-NF) and RFCXXX slice = CE/PE-CE/PE), feel free to provide any suggestion.
Note that section 3.4.2 and 3. have imho misleading titles (3.4.2 should be something like “TN Slice segmentation” and 3.5 realisation of “TN slices”



  *   Section 3.5. Why 1 to N mapping? Are you sure the split between UP and CP would lead to a single 5G slice mapped into multiple RFC XXXX slices? The number of RFC XXXX should be significantly lower than the number of 5G slices otherwise we risk to have serious scalability issues.

  *   This is one deployment option. It is common practice in to separate CP and UP in different contexts when transported in the IP Network. (NB: this is an option, which I have seen in a couple of deployments  - I am not saying it must be this way - ). Considering intent-based Data models such as “draft-ietf-teas-ietf-network-slice-nbi-yang”, you can certainly create one slice for CP (realized for example with an L3 VRF for Control plane) and another for UP (realized with another L3 VRF for UP). That allows to express different types of Transport SLAs for each (since they differ a lot). One key intention of this section is to explain that the integration of a 5G Slice in the Transport is more complex than a basic 1:1 mapping (i.e. here are plenty of option: pick up the one you need based on your requirements, scale, cost etc… you can mix and match options).
  *   Scaling is a different story: I agree that folks have to be careful at how they build (and sell/TTM) their services, but that’s out of the scope of this document 😊.  Thinking of the example CP, the CP is actually shared by all 5G slices … so there is no extra scaling constraint here (#5G slice  roughly equals  #TN slices). Again, this is all about service definition and pricing, you may want to pack multiple 5G private slices on a same TN slice  (cheap service) while providing a dedicated TN Slice for Tesla (premium service). Mix and match ... there is a infinite combination of architectures and mappings.





  *   One interesting topic to address would be the case of TN slices composed by multiple segments (I sent some text to describe it a while back). The stitching of the different segments would be a nice problem to be addressed.





[RR]  Segmentation is already in used (defined section 3.4.2) to decompose the NF-NF path (TN slice). I assume you might be thinking of multiple TN domains. If so the placeholder is section “3.4.3 additional segmentation and domains”. The overall idea is to have AC as the stitching swiss-knife (nbi/acaas data model for automation of the connectivity if needed).

We can add an example made up of two domains like: “CEdomain1—AC1--TN domain 1 --- AC2 ----TN domain2 ---- AC3----CEdomain2”.




Thanks,
Daniele