[Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)

["Dongjie (Jimmy)" <[e-mail]>]

Dear authors and WG,

Thanks for the efforts in updating the document. I’ve read the diffs between -04 and -09, and please find below a few comments to the changes.

The line numbers generated by the idnits are used.


133        technologies.  Specifically, this document explains how RFC 9543
134        Network Slices are realized within provider networks and how such
135        slices are stitched to Transport Network resources in a customer site
136        in the context of Transport Network Slices (Figure 1).

[Jie] Suggest to change this to: this document explains one approach of realizing RFC 9543 Network Slices within provider networks…



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.


186        resource control at the Provider Edges (PEs), (3) coarse-grained

187        resource control at within the provider network,

[Jie] s/at within/within



432        While in most cases CEs connect to PEs using IP (e.g., VLANs

433        subinterface on a Layer 3 interface), a CE may also connect to the

[Jie] s/VLANs subinterface on a Layer 3 interface/via layer-3 VLAN subinterfaces



573        A TN slice might be considered as a variant of horizontal composition

574        of Network Slices mentioned in Appendix A.6 of [RFC9543].

[Jie] For composition of network slices, it is suggested to also add a reference to draft-li-teas-composite-network-slices.



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.



790        that does not apply to subsequent slices.  Let us consider the

791        example depicted in Figure 10 to illustrate this deploloyment.  In

[Jie]  s/deploloyment/deployment



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


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.


2049    6.  PEs Underlay Transport Mapping Models


2058       It is worth noting that TN QoS Classes and underlay transport are

2059       orthogonal.


2091       Similar to the QoS mapping models discussed in Section 5, for mapping

2092       to underlay transports at the ingress PE, both 5QI-unaware and 5QI-

2093       aware models are defined.

[Jie] Does it mean the underlay transport can be aware of 5QI, while is orthogonal to TN QoS Classes? Then how are the QoS mapping models combined with the underlay transport mapping model? For example, can the 5QI-unaware QoS model be combined with the 5QI-aware underlay transport mapping model?  Or they always need to be consistent on 5QI-aware or unawareness?


2404    7.2.2.  Scheme 2: TE Paths with Fixed Bandwidth Reservations



2410       slice.  Note that the "reservations" would be in the mind of the

2411       transport controller - it is not necessary (or indeed possible for

2412       SR-TE) to reserve bandwidth at the network layer.

[Jie] With some mechanisms resource reservation can also be done on the network devices. If section 7.2.2 only talks about bandwidth reservation in the mind of the controller, it is suggested to make this explicit in the title of this section.

As for segment routing with resource reservation at the network layer, this document may consider to add a reference to draft-ietf-spring-resource-aware-segments.


Best regards,
Jie


From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Thursday, August 22, 2024 2:28 AM
To: TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
Subject: [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)

All,

This starts the 2nd working group last call on
https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/

Please note that the previous last call was for version 4 of the document and several changes have been made to the document since then. The changes have been discussed on the list and a summary presented during the WG session in IETF 120.

As this is a 2nd last call that is primarily focused on changes since the previous last call, it closes in *one" week. The working group last call ends on August 28th, 2024. Please send your comments to the working group mailing list.

A diff (v4-v9) can be found at:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-teas-5g-ns-ip-mpls-04&url2=draft-ietf-teas-5g-ns-ip-mpls-09&difftype=--html

Thank you,
Pavan and Oscar
ps: The following comment from Greg will be considered as part of this 2nd LC -
https://mailarchive.ietf.org/arch/msg/teas/Pr7hvoB_RS9ZgGIRGEdCf2rn4bE/