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

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

Hi Krzysztof,

Thanks for the feedback and sorry for the late reply. I’ve read the diff of -09 and -10,  which looks good in general.

Please find some further replies inline:

Best regards,
Jie

From: Krzysztof Szarkowicz [mailto:[e-mail]]
Sent: Friday, September 6, 2024 11:53 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: [e-mail] <[e-mail]>; TEAS WG <[e-mail]>; TEAS WG Chairs <[e-mail]>
Subject: Re: [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)

Dear Jie,

Please see my comments below.


Best regards,
Krzysztof



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

[Jie]Thanks for the update.



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.

[Jie] The sentence right before the one I quoted says:

      “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). ” Also the previous paragraph talks about mapping between 3GPP and IETF network slice services.

This indicates the text following that sentence continues talking about the mapping between 5G slices to TN network slices. It is OK to mention the mapping is between customer sites and provider networks, while it is better to mention it is about “network slice mapping”.

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

[Jie] This term is introduced by this document, and draft-ietf-teas-5g-network-slice-application uses it just for consistency with this document. It is fine if you think it has been clarified in this context.


[Krzysztof] In the context of mapping, this section already references draft-ietf-teas-5g-network-slice-application (one paragraph earlier).

[Jie] It is OK as long as both paragraphs talk about network slice mapping. Then my comment above applies.




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.

[Jie] The reference would be informative and there is no limit on the document status.

That said, it is just a suggestion and is on the authors’ discretion.




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.

[Jie] Agree it may be a common model in some deployments , but AFAIK it is not the default procedure for creating 5G slices. There is some presumption about specific deployment model, which IMO needs to be made clear either in the title or in the beginning of this subsection.

Specifically, for the text “the creation of the "first slice" can be subject to a specific logic that does not apply to subsequent slices”, is there anything in 3GPP which could be referenced?




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.

[Jie] Thanks for the clarification. So you confirmed that per-path BW reservation would be used for the approach described in this document.

Then my question still applies: does per-path BW reservation conflict with the “coarse-grained resource control” model as mentioned in the introduction?



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.

[Jie] It may depend on the operation model, for some operators the planning and allocation of IP addresses to mobile network functions is the duty of the mobile team.



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.

[Jie] Thanks for the clarification. I’m fine with the updated sentence. Basically any combination between the QoS model and the underlay transport mapping model is allowed, is that correct?



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.

[Jie] OK.

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

[Jie] That’s fine if the authors consider resource-aware segments as new technology. Then I’d suggest to make some changes to the text below:

OLD:  it is not necessary (or indeed possible for SR-TE) to reserve bandwidth at the network layer

NEW: it is not necessary (or indeed possible for current SR-TE technology) to reserve bandwidth at the network layer



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/

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