Hi Mike, Thank you for the careful review. Went with most all your suggestions as you can see at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.txt&url_2=https://boucadair.github.io/5g-slice-realization/mike-rtgdir-review/draft-ietf-teas-5g-ns-ip-mpls.txt Please see inline for where the current text is left as it is. Cheers, Med > -----Message d'origine----- > De : Mike McBride via Datatracker <noreply@xxxxxxxx> > Envoyé : mercredi 29 janvier 2025 06:38 > À : rtg-dir@xxxxxxxx > Cc : draft-ietf-teas-5g-ns-ip-mpls.all@xxxxxxxx; last- > call@xxxxxxxx; teas@xxxxxxxx > Objet : Rtgdir last call review of draft-ietf-teas-5g-ns-ip-mpls- > 15 > > > Reviewer: Mike McBride > Review result: Has Nits > > The following suggestions make the document more > readable/understandable to me. > Well done, good document. > > 1. Introduction > > Existing: > 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). > > Better: > This document describes 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). > > Best?: > This document describes how RFC 9543 Network Slices are realized > within provider networks and how such slices are stitched to > Transport Network resources in a customer site (Figure 1). > [Med] Left the current as there might be other approach to realize slicing (hence "an approach" .."). > Existing: > Concretely, the model uses (1) Layer 2 Virtual Private Network > (L2VPN)... > > Better (there are 3 uses of "concretely" in this document and > they can all be removed, it's distracting): The model uses (1) > Layer 2 Virtual Private Network (L2VPN)... > [Med] ACK. Removed all of them. > Existing: > Figure 1 uses "SDP" and it isn't defined until page 13. Please > consider defining it somewhere in the introduction. > [Med] Sure. Added a new sentence right after the figure. > 3.2. 5G Network Slicing versus Transport Network Slicing > > Existing: > Network slicing has a different meaning in the 3GPP mobile world > and transport world. > > Better: > Network slicing has different meanings in the 3GPP mobile and > transport worlds. > [Med] Left current. We used to have a similar construct in the past but this was confusing for some readers. See, e.g., Adrian's comment at https://mailarchive.ietf.org/arch/msg/teas/_MpVJJ8mqSq7dbDlG5RgOq5IokM/. > 3.4.1. 5G End-to-End Slice Orchestration Architecture > > Existing: > This framework permits to manage connectivity together with SLOs. > > Better: > This framework allows for managing connectivity with SLOs. > [Med] ACK. > 3.5. Mapping 5G Network Slices to Transport Network Slices > > Existing: > In such a case, the Service Level Agreement (SLA) differentiation > of slices would be entirely controlled at the 5G control plane, > for example, with appropriate placement strategies: this use case > is represented in Figure 9, where a User Plane Function (UPF) for > the Ultra Reliable Low Latency Communication (URLLC) slice is > instantiated at the edge cloud close to the gNB Centralized Unit > User Plane (CU-UP) for better latency/jitter control, while the > 5G control plane and the UPF for eMBB slice are instantiated in > the regional cloud. > > Better: > In this case, the Service Level Agreement (SLA) differentiation > of slices would be entirely controlled by the 5G control plane > using appropriate placement strategies. This use case is > illustrated in Figure 9, where a User Plane Function (UPF) for > the Ultra Reliable Low Latency Communication (URLLC) slice is > instantiated at the edge cloud, close to the gNB Centralized Unit > User Plane (CU-UP), to improve latency and jitter control. The 5G > control plane and the UPF for the eMBB slice are instantiated in > the regional cloud. > [Med] Went with almost all your edits. Kept the "for example", though. > 3.6. First 5G Slice versus Subsequent Slices > > Existing: > The model described here in which the control plane is shared > among multiple slices is likely to be common; it is not > mandatory, though. > > Better: > The model described here, in which the control plane is shared > among multiple slices, is likely to be common; it is not > mandatory however. > [Med] Done. > Figure 16: MPLS Hand-off with Option C > > Existing: x Logical interface represented by a VLAN on s physical > interface > > On figures 12 & 15 it just says .."on a physical interface". Did > you mean to add "s" here for like "source"? I'm going to guess > you meant "on a physical interface" since s and a keys are next > to each other. > [Med] You got it. Fixed. Thank you again for the good suggestions. ____________________________________________________________________________________________________________ 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
