[Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
"Dongjie (Jimmy)" <jie.dong@huawei.com> Sat, 14 September 2024 02:14 UTC
Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C0EC169437; Fri, 13 Sep 2024 19:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtzco7u702_B; Fri, 13 Sep 2024 19:14:24 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70157C14F712; Fri, 13 Sep 2024 19:14:23 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4X5F3n0dByz6K67f; Sat, 14 Sep 2024 10:09:25 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 9EA21140519; Sat, 14 Sep 2024 10:14:20 +0800 (CST)
Received: from dggpemf100007.china.huawei.com (7.185.36.214) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sat, 14 Sep 2024 03:14:19 +0100
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf100007.china.huawei.com (7.185.36.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 14 Sep 2024 10:14:17 +0800
Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.011; Sat, 14 Sep 2024 10:14:16 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Thread-Topic: [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
Thread-Index: AQHa8/f42As3RpEFzUqMpkruwGjZ2bIylUPQgBfmagCACyJ9IA==
Date: Sat, 14 Sep 2024 02:14:16 +0000
Message-ID: <19d31c2b1128439594dc6bbacbf2ee5b@huawei.com>
References: <CA+YzgTuwRDSxfy7rHR21A3LqAmRcQtcFZWo1KD6KQZaEFMcODQ@mail.gmail.com> <d27ef01a787a42a9945b818124728c2c@huawei.com> <4E60C28E-D0D2-424B-A49F-D22CD2F0760C@gmail.com>
In-Reply-To: <4E60C28E-D0D2-424B-A49F-D22CD2F0760C@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/alternative; boundary="_000_19d31c2b1128439594dc6bbacbf2ee5bhuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: QETBG37WYXGEBNRDB44MGSBPRM4KMZUQ
X-Message-ID-Hash: QETBG37WYXGEBNRDB44MGSBPRM4KMZUQ
X-MailFrom: jie.dong@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "EXT-vishnupavan@gmail.com" <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/c601GkF78UMh4m4Rnl5X2eSjSlg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
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:kszarkowicz@gmail.com] Sent: Friday, September 6, 2024 11:53 PM To: Dongjie (Jimmy) <jie.dong@huawei.com> Cc: EXT-vishnupavan@gmail.com <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>; TEAS WG Chairs <teas-chairs@ietf.org> 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=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>> 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:vishnupavan@gmail.com] Sent: Thursday, August 22, 2024 2:28 AM To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>> Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>> 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 -- teas@ietf.org<mailto:teas@ietf.org> To unsubscribe send an email to teas-leave@ietf.org<mailto:teas-leave@ietf.org>
- [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip… Vishnu Pavan Beeram
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Dongjie (Jimmy)
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Greg Mirsky
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… OSCAR GONZALEZ DE DIOS
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Greg Mirsky
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Xuesong Geng
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Krzysztof Szarkowicz
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… mohamed.boucadair
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Dongjie (Jimmy)
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Richard Roberts
- [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-n… Krzysztof Szarkowicz