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

[[e-mail]]

Hi Adrian,

Thank you for diving into this.

Please see inline.

Cheers,
Med

De : Adrian Farrel <[e-mail]>
Envoyé : vendredi 27 septembre 2024 20:08
À : 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 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

[Med] I agree that if this is ambiguous for readers, then this should be amended. However, let me first explain why we didn’t make a change: passing information between domains (handoff) can be for various purposes (QoS mapping, slicing, ACL, etc.). Of course, this document focuses on the “handoff for slice mapping”. This is why Section 4 uses the following wording:

  “..few hand-off
  methods for slice mapping between customer sites and provider
   networks.”

If we defined “handoff” as specific to slices, then we need to touch the text above because saying “Handoff methods for slice mapping” will be redundant.

Would the following change makes the intent clearer:

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).  Passing information between customer
   sites and provider networks is referred to as the "hand-off".
   Section 4 lists a set of hand-off methods for slicing mapping purposes.

> 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.
[Med] that’s because we marked it as a note.

> 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

[Med] I see Jie commented on this one. Will follow-up there.

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

[Med] Let’s move that Section 4.2.1 to appendix.
____________________________________________________________________________________________________________
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.