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

[Krzysztof Szarkowicz <[e-mail]>]

Dear Jie,

Please see my comments below.


Best regards,
Krzysztof


> On Aug 28, 2024, at 11:21, Dongjie (Jimmy) <jie.dong=[e-mail]> wrote:
> 
> 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…

[Krzysztof] Ack. We will update the text in the next revision.
 
> 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). 
>  
> 186        resource control at the Provider Edges (PEs), (3) coarse-grained
> 187        resource control at within the provider network, 
>  
> [Jie] s/at within/within
>  

[Krzysztof] Ack. We will update the text in the next revision.

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

[Krzysztof] Ack. We will update the text in the next revision.

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

[Krzysztof] We reference RFC 9543 for slice composition. We don’t see as necessary to reference individual drafts at this point of time.

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

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

[Krzysztof] Ack. We will update the text in the next revision.

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

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

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

[Krzysztof] We will slightly update the first sentence: “It is worth noting that TN QoS Classes and underlay transport are each related to different engineering objectives”. And, since they are independent and addressing different engineering objectives, then yes, the 5QI-unaware QoS model can be combined with the 5QI-aware underlay transport mapping model, as described in subsections of Section 5 and Section 6.

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

[Krzysztof] Good catch! We will adjust the text in this section to “allow" reservations in the controller or the network devices. 

[Krzysztof] As the draft title says, this draft focuses on “current IP/MPLS Technologies”, with broad deployment status, therefore we don’t see the possibility to reference draft-ietf-spring-resource-aware-segments, which is new, emerging technology.


>  
> Best regards,
> Jie
>  
>  
> From: Vishnu Pavan Beeram [mailto:[e-mail]] 
> Sent: Thursday, August 22, 2024 2:28 AM
> To: TEAS WG <[e-mail] <mailto:[e-mail]>>
> Cc: TEAS WG Chairs <[e-mail] <mailto:[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/
>  <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/
> _______________________________________________
> Teas mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>