[Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

[Adrian Farrel <[e-mail]>]

Hi Med,

 

Sorry, I was slower than I promised.

 

My first task was to check back to the email exchange with Jie and see whether my memory of not all issue being resolved was true.

The most recent email exchange seems to be from Krzysztof at  <https://mailarchive.ietf.org/arch/msg/teas/ngKXuUK0nqHq_g5Hok4BVttLML0/> https://mailarchive.ietf.org/arch/msg/teas/ngKXuUK0nqHq_g5Hok4BVttLML0/

I’ve copied the relevant parts below and added my own comments.

 

Cheers,

Adrian

 

> 177        3, or Layer 4).  The realization of the mapping between customer

> 178        sites and provider networks is refered to as the "hand-off".

> 179        Section 4 lists a set of such hand-off methods.

>  

> [Jie] From the context it seems the mapping refers to the mapping between 5G network slices and network slices in TN domain. But the text here just says mapping is between customer sites and provider networks. It is suggested to clarify the scope of the mapping is for network slices.

>  

> As for the term “hand-off”, it seems it is used in the wireless world for something else. If this draft wants to use this term for the network slice mapping mechanism, I’d suggest to make it clear that it is “network slice hand-off in data plane”.

>  

> And it is suggested this section also refer to draft-ietf-teas-5g-network-slice-application for the methods of network slice mapping/hand-off in data plane. 

 

[Krzysztof] Not sure, how you come to the conclusion that the context indicates that mapping is between 5G network slices and network slices in the TN domain. We clearly described in the text, that it is between customer sites and provider networks, so scope is already clearly specified

 

[Krzysztof] “hand-off” is very generic term, used in many contexts. We clarified the term “hand-off” in the context of this draft, and using it in the similar manner as term “hand-off/handoff” in the draft-ietf-teas-5g-network-slice-application, for consistency between two drafts.

 

[Krzysztof] In the context of mapping, this section already references draft-ietf-teas-5g-network-slice-application (one paragraph earlier). 

 

There seems to have been no change for this. That’s a shame. If Jie is confused as to the meaning of the text, then the text is not clear. So the first change needs to clarify the meaning.

 

Krzysztof says that the mapping is between customer sites and provider networks and that is what the text says. To be clear, that means F(customer site) = provider network. 

But I’m also confused ☹

As Krzysztof notes, the previous paragraph, talks about “mapping” as well. But there it is clear that it is the services (and service parameters) that are being mapped, not site/network.

Section 3.5 and section 5 are all about mapping.

But hand-off is discussed in section 4 (as pointed to the text).

And section 4 is explicit about mapping parameters in order to achieve hand-off between domains/networks. And says “hand-off methods for slice mapping between customer sites and provider networks”

 

So, my conclusion is that Jie has correctly indicated a point of ambiguity in the text. It’s only the Introduction, so it is not critically important. But it would be nice for the reader to not have to unpick the document in order to correct a misapprehension gained while looking at the Introduction. So, perhaps…

 

OLD

   The 5G control plane uses the Single Network Slice Selection

   Assistance Information (S-NSSAI) for slice identification

   [TS-23.501].  Because S-NSSAIs are not visible to the transport

   domain, 5G domains can expose the 5G slices to the transport domain

   by mapping to explicit data plane identifiers (e.g., Layer 2, Layer

   3, or Layer 4).  The realization of the mapping between customer

   sites and provider networks is refered to as the "hand-off".

   Section 4 lists a set of such hand-off methods.

NEW

   The 5G control plane uses the Single Network Slice Selection

   Assistance Information (S-NSSAI) for slice identification

   [TS-23.501].  Because S-NSSAIs are not visible to the transport

   domain, 5G domains can expose the 5G slices to the transport domain

   by mapping to explicit data plane identifiers (e.g., Layer 2, Layer

   3, or Layer 4).  The realization of the mapping between slice

   parameters at customer sites and those in the provider network

   is referred to as the "hand-off" between the networks.  Section 4

   describes some possible hand-off methods.

END

 

> 782     3.6.  First 5G Slice versus Subsequent Slices

>  

> 784        An operational 5G Network Slice incorporates both 5G control plane

> 785        and user plane capabilities.  For instance, consider a slice based on

> 786        split-CU in the RAN, both CU-UP and Centralized Unit Control Plane

> 787        (CU-CP) need to be deployed along with the associated interfaces E1,

> 788        F1-c, F1-u, N2, and N3 which are conveyed in the TN.  In this regard,

> 789        the creation of the "first slice" can be subject to a specific logic

> 790        that does not apply to subsequent slices.

>  

> [Jie] Section 3.6 assumes that the deployment of the first 5G slice is different from the deployment of subsequent slices. This may be true for the example in Figure 10, where the control plane for different 5G slices are shared. While it is possible the control plane of different 5G slices need to be separated, then the deployment of TN slices would be different from the description in this section.

>  

> It is suggested to clarify the presumption of shared slice for control plane in the beginning of section 3.6.

 

[Krzysztof] Section 3.6 describes very common model, where CP is shared between slices (so, 2nd slice shares the CP with 2st slice), as an example (“For instance”). At the same time, there are no presumptions. Depending on the operational guidelines, operator might deploy slices with shared CP, or slices with separate CPs. Or, could have some mixture of slices with shared CPs, and slices with separate CPs.

 

I think a paragraph has been added to give exactly the clarification Jie asked for (although I don’t see why the new paragraph is indented.

 

> 918           methods used here can range from careful network planning, to

> 919           ensure a more or less equal traffic distribution (i.e., equal cost

> 920           load balancing), to advanced TE techniques, with or without

> 921           bandwidth reservations, to force more consistent load distribution

> 922           even in non-ECMP friendly network topologies. 

>  

> [Jie] Section 3.7 mentions that coarse-grained resource control with up to 8 traffic classes is used at the transit links in the provider network. Then in capacity planning/management, it mentions “advanced TE techniques, with or without bandwidth reservation”. It is not very clear whether bandwidth reservation is at coarse granularity (up to 8 traffic classes), or it can be done at finer granularity (e.g. per path)? If it is the latter, does it conflict with “coarse-grained resource control”?

 

[Krzysztof] We are not perspective, and not dictating any concrete granularity of bandwidth reservation. Typical deployments today use non-coarse, per path (not per traffic class) BW reservation. Some time ago, Diff-Serv Aware Traffic Engineering BW reservation modes (RFC 4128) were standardized by IETF. These model could be in prinicple used here as well. Saying that, these models didn’t gain much attention among operators (real production network deployments), comparing to simple per-path BW reservation model.

 

It looks as though you agree with each other that per-path reservation is the main way to go. So, can we just concentrate on getting the text clear.

 

Actually, it is possible that there is a little refinement we can do in this section. The two bullet points talk about “Fine-grained resource control at the PE” and “Coarse-grained resource control at the transit links,” while the text that Jie quoted talks about bandwidth reservation. Additionally, Figure 11 mentions “fine-grained QoS” and “coarse-grained QoS” while the figure, by using a single PE-PE slice confuses the course bandwidth assignment to the NRP with the fine bandwidth assignment to the PE-PE path.

 

Can I suggest:

OLD

with or without bandwidth reservations

NEW

with or without per-path bandwidth reservations

END

 

> 1097    4.2.1.  An Example of Local IPv6 Addressing Plan for Network Functions

>  

> [Jie] I appreciate the update in the text which explains the example of embedding S-NSSAI into IPv6 address. While since it is about the IPv6 addressing of the 5G NFs, which is out of the scope of the TN network, and IMO not the focus of this document. It is suggested to either move this section to the appendix or remove it from this document.

 

[Krzysztof] IP addressing and IP allocation scheme is an important aspect of TN network. One allocation scheme is provided as an example in section 4.2.1.

 

I don’t think Jie was questioning the validity of the example. However, it looks (to me?) that the encoding of the S-NSSAI into the IPv6 address is done entirely in the NF, and the fact of the encoding is transparent to the TN. While the TN routes the IP address, the low-order 32 bits are not inspected by the TN. 

 

The imbalance appears to be that 4.2.1 is the only detailed example provided in Section 4. No detailed representative example is given for the VLAN or MPLS hand-offs. It might, therefore, be appropriate to move 4.2.1 to an appendix (it is clearly not normative) and simply include one line to say “An example of how the S-NSSAI could be encoded in an IPv6 address is given in Appendix Foo.”