[Teas] Re: Last-gasp review of draft-ietf-teas-5g-ns-ip-mpls-11

[[e-mail]]

Hi Adrian,

Thank you for the careful review.

A diff to track the changes made so far can be seen here: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-teas-5g-ns-ip-mpls&url_2=https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.txt.

Please see inline.

Cheers,
Med

De : Adrian Farrel <[e-mail]>
Envoyé : vendredi 27 septembre 2024 21:29
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc : 'TEAS WG Chairs' <[e-mail]>
Objet : Last-gasp review of draft-ietf-teas-5g-ns-ip-mpls-11

Hi,

Here (finally) is my additional review of this draft. Sorry to have
taken a few additional days.

Other than the comments (arising from Jie's review), I have only
found a small points and a couple of nits.

Not sure whether I should have spotted these in previous reviews. If so,
sorry.

Thanks for all the work.

Cheers,
Adrian

===

idnits shows " Unused Reference: 'TR-GSTR-TN5G' "

[Med] Argh. Fixed. Thanks.

---

Section 2, having said the document makes use of the terms defined in
RFC 9543, proceeds to provide a new definition of "customer" and
"provider". I wonder whether those new definitions are necessary, and
if they are I think great care is needed to achieve disambiguation.

[Med] Section 2 also says right after the ref to 9543: "See Section 3.3 for the contextualization of some of these terms."

We used to have "customer" and "provider" entries be part of 3.3 but we moved them here because we received a comment to group all defs.

---

In Section 3.1, piping ("|") is used to indicated quoted text from 3GGPP
documents. That's good.
But:
- It is probably de trop to use quotation marks as well.
[Med] "" were used to ease demux the quotation from the source.
- It appears as though the reference is part of the quote.

[Med] moved the source refs to be positioned before the citation and removed the redundant "".
---

3.2.1

Ditto the use of | and "
[Med] Fixed.

---

3.2.2

I don't object to one word of the text in 3.2.2. I do find it peculiar
that, while 3.2.1 is nicely quoted from 3GPP documentation, the text in
this section is longer and un-cited.

I should imagine that the paragraph...
    The objective of Transport Network Slicing is
...should be founded in a 3GPP definition.

[Med] We can't formally cite any reference here where the exact words are used. The definition inspires from 3GPP docs, especially from the following:

"When providing an end to end communication service, the network may use non-3GPP parts (e.g. Data centre network (DCN), Transport network (TN)) in addition to the network components defined in 3GPP. Therefore, in order to ensure the performance of a communication service according to the business requirements, the 3GPP management system has to coordinate with the management systems of the non-3GPP parts (e.g., MANO system) when preparing a network slice for this service. This coordination may include obtaining capabilities of the non-3GPP parts and providing the slice specific requirements and other requirements on the non-3GPP parts. Figure 4.7.1 illustrates an example for the coordination with management of TN part (e.g., directly or via MANO system)."

+ (extract of TN specific objectives)

"The network slice related requirements include requirements such as: area traffic capacity, charging, coverage area, degree of isolation, end-to-end latency, mobility, overall user density, priority, service availability, service reliability, UE speed."


While the first half of the paragraph...
   Transport Network Slicing provides various degrees of sharing of
   resources between slices
...presumably stems from 9543

[Med] We can cite Section 8 of 9543.

The rest of the text is explanatory in the context of this document (and
maybe should say so).

[Med] Added the following NEW:

"The following further elaborates on how Transport Network Slicing is
defined in the context of this document."

---

Slice scopes and SDP locations.

It is all really confusing to me, and I do not arrive at anything other
than contradictions from the text :-(

Figure 1 shows the TN slice and also shows the type 3 and type 4 SDP
locations.
[Med] These SDPs for "RFC 9543 Network Slice", not the full TN slice. We have the following in the introduction:

   Specifically, this document describes an approach to
   how RFC 9543 Network Slices are realized within provider networks and
   how such slices are stitched to Transport Network resources in a
   customer site in the context of Transport Network Slices (Figure 1).
   Concretely, the realization of an RFC 9543 Network Slice (i.e.,
   connectivity with performance commitments) involves the provider
   network and partially the AC (the PE-side of the AC).  This document
   assumes that the customer site infrastructure is over-provisioned and
   involves short distances (low latency) where basic QoS/scheduling
   logic is sufficient to comply with the Service Level Objectives
   (SLOs).

But, an SDP is the point at which the slice service begins or ends. It
is the edge of the slice.

Either:
- You are saying that a transport slice does not map perfectly to an
  IETF slice
Or:
- There is something wrong with this and the text in 3.4.2.

I don't think any of this changes any of the technical details or
practicalities of the solutions described. It just that the description
seems plain wrong.

For example, where you talk about mapping service parameters: where
is that mapping performed? The question, I suppose is, are you
constructing a TN slice that encompasses network resources that are
both IETF and non-IETF. In that case, the service parameters are
mapped at the edge of the TN slice, and then they are mapped again
at the network boundary at the start of the IETF technology.

If your intention is that the TN slice is constructed from elements of
the customer domain (possibly non-IETF) and the provider domain (IETF),
that would be fine, but I think the TN slice end points are still the
SDPs.

If, conversely, you are saying that the TN slice is a composite of
customer domain slice and IETF slice, then you have the SDPs correctly
placed, but you have not made this composite clear.

[Med] 3.4.1 says:

   A TN slice relies upon resources that can involve both the provider
   and customer TN domains.  More details are provided in Section 3.4.2.

   A TN slice might be considered as a variant of horizontal composition
    of Network Slices mentioned in Appendix A.6 of [RFC9543].

[Med] Updated 3.4.2 to remind that this is about 9543 network slice deployments.

It does not help that 3.4.2 goes on to say:
   The concept of distributed PE (Section 3.3.4) assimilates CE-based
   SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as SDP
   Type 3 or 4 in this document.

The problem is not with the text, but with the fact that your Figure 6
shows the TN slice extending to the CEs in a model where the CEs are
distinct from the PEs. (To me it seems that you are doing types 1 and 2
in this document with the case of distributed PE assimilating types 3
and 4.)

I start to run into some of this again in Section 4. For example, in 4.1
   In this option, the RFC 9543 Network Slice, fulfilling connectivity
   requirements between NFs that belong to a 5G slice, is represented at
   an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as
   depicted in Figure 12.
That suggests to me that the model in your head is that the VLAN ID is
indicative of either:
- onto which IETF slice the SDP should place the traffic (the traffic
  is at that stage not yet sliced only marked for slicing)
or:
- on which IETF slice the traffic is flowing (the traffic has already
  been sliced and the SDP is actually at the end of the TN slice).

To complete my whining about this, 4.2 shows the "tunnels representing
slices" as extending all the way to the NFs (CEs not marked). Surely,
in that case, the SDP is at the end of the tunnel?


I'd be quite happy with either or any approach. I just want the
description to match.

---

3.6

   At the time of writing (2024), Section 6.1.2 of [NG.113] specifies

Well...
NG.113 is a dated reference. Doesn't that mean that you can simply say

   Section 6.1.2 of [NG.113] specifies

While it is true that 3GGP's "5GS Roaming Guidelines" may change over
time. The referenced Version 4 dated 2021 will not change.

[Med] Fixed.
---

3.7

s/of [RFC9522])./of [RFC9522]./
[Med] Fixed. Thanks.

---

Figure 11

Is there an arrow head missing from the left hand end of the line within
the right hand P node?
[Med] Thanks for catching this. There was a missing +.

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: 24 September 2024 09:47
To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: 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 Adrian,

Deal! Thank you for your efforts.

I also hope that Jie can check and let us know if we missed any of his comments.

Cheers,
Med

De : Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 24 septembre 2024 10:22
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Objet : [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

Thanks to all for the hard work on this document. It is definitely getting much better (and shorter) which is a good thing for all of us.

There does seem to have been a lot of changes sine the first last call, and even since the second one. It also looks (to me) that there are a few of Jie's comments still unresolved.

I plan to scan the doc tonight and I'll try to suggest resolutions for the points that look to be still open.

A
On 24/09/2024 10:05 CEST [e-mail]<mailto:[e-mail]> wrote:


Hi Pavan, all,

FWIW, the changes are now implemented in the public version together with additional follow-up comments from Jie: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/11/.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : lundi 9 septembre 2024 15:34
À : 'Vishnu Pavan Beeram' <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Objet : RE: [Teas] Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

Hi Pavan, all,

Thanks for sharing your conclusions.

Looks good to me. Fixed right now the ref nits: https://github.com/boucadair/5g-slice-realization/commit/3c11d6e6baa2f50a10a95904c8abb29753e91034. These nits can be queues for a next iteration when we will have more comments, but we can release a new version if you prefer so. Thanks.

Cheers,
Med

De : Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 9 septembre 2024 10:04
À : TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Objet : [Teas] Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"

WG,

We sent a liaison statement [1] in June to multiple 3GPP groups seeking feedback on our WG draft that discusses "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies" [2].
We have received replies from 3GPP-TSGSA-SA2 [3], 3GPP-TSG-SA-WG5 [4] and O3GPPTSGRAN3 [5]. We request the WG to review the feedback and chime in with your thoughts/opinions.

The following is our (chairs') interpretation of the feedback that was received.


  *   3GPP-TSGSA-SA2:

     *   Remove Appendices B.1 and B.2 and just have a reference to TS-23.501
     *   No endorsement of the "Hand-off" options discussed in Section 4 and the QoS Mapping Realization Models in Section 5

        *   This need not warrant any changes to Sections 4 and 5. We need to ensure that the language used in these two sections doesn't imply any endorsement by 3GPP.

  *   3GPP-TSG-SA-WG5:

     *   Fix the reference to 3GPP TS 28.530

  *   O3GPPTSGRAN3:

     *   Inaccuracies exist in Appendix B.3. Suggest adding references to TS-38.300 and TS-38.401

        *   In other words, this is a recommendation to remove Appendix B.3.

Based on the above, our recommendation is to remove Appendix B (including the Transport Network specific sub-section) and add the suggested references in the Introduction. The authors have published a new revision (rev 10) with Appendix B removed. Please review the latest changes and let us know if there are any comments/concerns.

Regards,
-Pavan and Oscar

[1] https://datatracker.ietf.org/liaison/1931/
[2] https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-ns-ip-mpls
[3] https://datatracker.ietf.org/liaison/1955/
[4] https://datatracker.ietf.org/liaison/1956/
[5] https://datatracker.ietf.org/liaison/1957/


____________________________________________________________________________________________________________

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.
_______________________________________________
Teas mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________

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