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

[[e-mail]]

Hi Jie,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

De : Dongjie (Jimmy) <[e-mail]>
Envoyé : dimanche 29 septembre 2024 17:04
À : [e-mail]; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : 'TEAS WG' <[e-mail]>; 'TEAS WG Chairs' <[e-mail]>
Objet : RE: [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

Hi Adrian, Med, and Krzysztof,

Sorry for the delayed reply. And thanks to Adrian for the analysis and suggestions. I think we are converging on the remaining comments.

Please see some further response inline with [Jie#2]:

From: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, September 28, 2024 2:08 AM
To: [e-mail]<mailto:[e-mail]>
Cc: 'TEAS WG' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

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/
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

[Jie#2] The proposed new text clarifies that “hand-off” refers to the “mapping between slices” in the customer sites and those in the provider network, this is much clearer. Thanks. Please note I use “mapping between slices” instead of “mapping between slice parameters”, as this section is about the mapping between slices in data plane. The slice parameters should have been negotiated in management plane.

[Med] As replied to Adrian, “handoff” is defined a generic term for passing information between domains. We then use “hand-off for slicing” when referring to Section 4.

Another small nit in this paragraph is it says “5G domains can expose the 5G slices to the transport domain”, while depending on the method used for slice mapping, specific 5G slices may or may not be exposed to the transport domain. Thus it is better to say “5G domains can map the 5G slices to the transport domain by using explicit data plane identifiers”.
[Med] It is not the 5G who maps but the transport network based on an information that is exposed by that network. Kept the old wording.


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

[Jie#2] I noticed the new paragraph added, it is helpful. My concern is more about the title of section 3.6 , as the whole section is about one specific deployment model of 5G slices, which is neither default nor mandatory. My suggestion would be to make this clear either in the title or the beginning of this section.

For example, the title could be changed to “ 3.6 One deployment model of 5G Slices and the corresponding TN Slices”.
[Med] The note makes it clear about available deployment approaches. The proposed title, however, does not reflect the main message of this section: operators may consider differentiated realization of the first slice vs subsequent ones.


> 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

[Jie#2] I think Krzysztof has confirmed that per-path bandwidth reservation is in scope. Actually my confusion was caused by firstly section 1 saying this approach is based on “coarse-grained resource control within the provider network (with up to 8 traffic classes)”, while section 3.7 saying per-path bandwidth reservation can be used. In my understanding, maintaining per-path bandwidth reservation state in the network is no longer “coarse-grained resource control”, do you agree?

If so, the resolution could be either change the statement about “coarse-grained control” in section 1, or exclude per-path bandwidth reservation from this document.
[Med] I still don’t follow this reasoning. Section 1 says:

   The realization model described in this document uses a set of
   building blocks commonly used in service provider networks.
   Concretely, the model uses (1) Layer 2 Virtual Private Network
   (L2VPN) [RFC4664] and/or Layer 3 Virtual Private Network (L3VPN)
   [RFC4364] service instances for logical separation, (2) fine-grained
   resource control at the Provider Edges (PEs), (3) coarse-grained
   resource control within the provider network, and (4) capacity
     management.  More details are provided in Sections 3.7, 5, 6, and 7.

Resource control and capacity are distinct dimensions. As indicated in the first reply, we are not prescriptive on which bw reservations schemes are in place.

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

[Jie#2] Adrian is right that the encoding of S-NSSAI in the lower bits of IPv6 address is transparent to the TN, thus it is not used in the TN domain. And as mentioned in the 3GPP liaison reply, the identification of 5G Slices does not rely on the encoding of IP address. To align with the 3GPP statement, it is suggested to move this example to the appendix, possibly with some clarification about the benefit of this encoding.

Best regards,
Jie
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.