[Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"
"Dongjie (Jimmy)" <jie.dong@huawei.com> Sun, 29 September 2024 15:03 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 3E470C14F5E3; Sun, 29 Sep 2024 08:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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_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 BUMtpTrZ5My3; Sun, 29 Sep 2024 08:03:40 -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 4E325C14F5E7; Sun, 29 Sep 2024 08:03:39 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XGnWH0NPnz67KCl; Sun, 29 Sep 2024 23:02:51 +0800 (CST)
Received: from lhrpeml500006.china.huawei.com (unknown [7.191.161.198]) by mail.maildlp.com (Postfix) with ESMTPS id 7A593140AE5; Sun, 29 Sep 2024 23:03:36 +0800 (CST)
Received: from dggpemf100009.china.huawei.com (7.185.36.128) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sun, 29 Sep 2024 16:03:35 +0100
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf100009.china.huawei.com (7.185.36.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 29 Sep 2024 23:03:33 +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; Sun, 29 Sep 2024 23:03:33 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"
Thread-Index: AQHbDllkBacq/71q2UGzl6ufBIzT9bJmEs2AgAAHEwCABVPJgIADXedw
Date: Sun, 29 Sep 2024 15:03:33 +0000
Message-ID: <5cbbfea3e46148bfa261034ce705afc4@huawei.com>
References: <CA+YzgTsztTc9OQ3qCKyD3uGfjncLF5EvbabPOC9pDJMdu7YprQ@mail.gmail.com> <DU2PR02MB101600A1E3A62551C41DC7E4A88682@DU2PR02MB10160.eurprd02.prod.outlook.com> <762136658.2244950.1727166111240@www.getmymail.co.uk> <DU2PR02MB10160A8C474C1F2443E3FDE6088682@DU2PR02MB10160.eurprd02.prod.outlook.com> <01da01db1108$3d1bbc40$b75334c0$@olddog.co.uk>
In-Reply-To: <01da01db1108$3d1bbc40$b75334c0$@olddog.co.uk>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.84.55.155]
Content-Type: multipart/alternative; boundary="_000_5cbbfea3e46148bfa261034ce705afc4huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: ZI5E4RBN7MJDCBS7UQ3BYOIKD4VC25VD
X-Message-ID-Hash: ZI5E4RBN7MJDCBS7UQ3BYOIKD4VC25VD
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: 'TEAS WG' <teas@ietf.org>, 'TEAS WG Chairs' <teas-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies"
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UiJ72tHqfv1NB7v1Hm-1j5IxKNw>
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 Adrian, Med, and Krzysztof, Sorry for the delayed reply. And thanks to Adrian for the analysis and suggestions. I think we are converging on the remaining comments. Please see some further response inline with [Jie#2]: From: Adrian Farrel <adrian@olddog.co.uk> Sent: Saturday, September 28, 2024 2:08 AM To: mohamed.boucadair@orange.com Cc: 'TEAS WG' <teas@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org> Subject: [Teas] Re: Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies" Hi Med, Sorry, I was slower than I promised. My first task was to check back to the email exchange with Jie and see whether my memory of not all issue being resolved was true. The most recent email exchange seems to be from Krzysztof at https://mailarchive.ietf.org/arch/msg/teas/ngKXuUK0nqHq_g5Hok4BVttLML0/ I’ve copied the relevant parts below and added my own comments. Cheers, Adrian > 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). There seems to have been no change for this. That’s a shame. If Jie is confused as to the meaning of the text, then the text is not clear. So the first change needs to clarify the meaning. Krzysztof says that the mapping is between customer sites and provider networks and that is what the text says. To be clear, that means F(customer site) = provider network. But I’m also confused ☹ As Krzysztof notes, the previous paragraph, talks about “mapping” as well. But there it is clear that it is the services (and service parameters) that are being mapped, not site/network. Section 3.5 and section 5 are all about mapping. But hand-off is discussed in section 4 (as pointed to the text). And section 4 is explicit about mapping parameters in order to achieve hand-off between domains/networks. And says “hand-off methods for slice mapping between customer sites and provider networks” So, my conclusion is that Jie has correctly indicated a point of ambiguity in the text. It’s only the Introduction, so it is not critically important. But it would be nice for the reader to not have to unpick the document in order to correct a misapprehension gained while looking at the Introduction. So, perhaps… OLD The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice identification [TS-23.501]. Because S-NSSAIs are not visible to the transport domain, 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). The realization of the mapping between customer sites and provider networks is refered to as the "hand-off". Section 4 lists a set of such hand-off methods. NEW The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice identification [TS-23.501]. Because S-NSSAIs are not visible to the transport domain, 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). The realization of the mapping between slice parameters at customer sites and those in the provider network is referred to as the "hand-off" between the networks. Section 4 describes some possible hand-off methods. END [Jie#2] The proposed new text clarifies that “hand-off” refers to the “mapping between slices” in the customer sites and those in the provider network, this is much clearer. Thanks. Please note I use “mapping between slices” instead of “mapping between slice parameters”, as this section is about the mapping between slices in data plane. The slice parameters should have been negotiated in management plane. Another small nit in this paragraph is it says “5G domains can expose the 5G slices to the transport domain”, while depending on the method used for slice mapping, specific 5G slices may or may not be exposed to the transport domain. Thus it is better to say “5G domains can map the 5G slices to the transport domain by using explicit data plane identifiers”. > 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. I think a paragraph has been added to give exactly the clarification Jie asked for (although I don’t see why the new paragraph is indented. [Jie#2] I noticed the new paragraph added, it is helpful. My concern is more about the title of section 3.6 , as the whole section is about one specific deployment model of 5G slices, which is neither default nor mandatory. My suggestion would be to make this clear either in the title or the beginning of this section. For example, the title could be changed to “ 3.6 One deployment model of 5G Slices and the corresponding TN Slices”. > 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. It looks as though you agree with each other that per-path reservation is the main way to go. So, can we just concentrate on getting the text clear. Actually, it is possible that there is a little refinement we can do in this section. The two bullet points talk about “Fine-grained resource control at the PE” and “Coarse-grained resource control at the transit links,” while the text that Jie quoted talks about bandwidth reservation. Additionally, Figure 11 mentions “fine-grained QoS” and “coarse-grained QoS” while the figure, by using a single PE-PE slice confuses the course bandwidth assignment to the NRP with the fine bandwidth assignment to the PE-PE path. Can I suggest: OLD with or without bandwidth reservations NEW with or without per-path bandwidth reservations END [Jie#2] I think Krzysztof has confirmed that per-path bandwidth reservation is in scope. Actually my confusion was caused by firstly section 1 saying this approach is based on “coarse-grained resource control within the provider network (with up to 8 traffic classes)”, while section 3.7 saying per-path bandwidth reservation can be used. In my understanding, maintaining per-path bandwidth reservation state in the network is no longer “coarse-grained resource control”, do you agree? If so, the resolution could be either change the statement about “coarse-grained control” in section 1, or exclude per-path bandwidth reservation from this document. > 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. I don’t think Jie was questioning the validity of the example. However, it looks (to me?) that the encoding of the S-NSSAI into the IPv6 address is done entirely in the NF, and the fact of the encoding is transparent to the TN. While the TN routes the IP address, the low-order 32 bits are not inspected by the TN. The imbalance appears to be that 4.2.1 is the only detailed example provided in Section 4. No detailed representative example is given for the VLAN or MPLS hand-offs. It might, therefore, be appropriate to move 4.2.1 to an appendix (it is clearly not normative) and simply include one line to say “An example of how the S-NSSAI could be encoded in an IPv6 address is given in Appendix Foo.” [Jie#2] Adrian is right that the encoding of S-NSSAI in the lower bits of IPv6 address is transparent to the TN, thus it is not used in the TN domain. And as mentioned in the 3GPP liaison reply, the identification of 5G Slices does not rely on the encoding of IP address. To align with the 3GPP statement, it is suggested to move this example to the appendix, possibly with some clarification about the benefit of this encoding. Best regards, Jie
- [Teas] Responses for LS on "Realization of Networ… Vishnu Pavan Beeram
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… Adrian Farrel
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… Adrian Farrel
- [Teas] Re: Responses for LS on "Realization of Ne… Dongjie (Jimmy)
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Re: Last-gasp review of draft-ietf-teas-5g… mohamed.boucadair
- [Teas] Re: Last-gasp review of draft-ietf-teas-5g… Adrian Farrel
- [Teas] Re: Last-gasp review of draft-ietf-teas-5g… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… Dongjie (Jimmy)
- [Teas] Re: Last-gasp review of draft-ietf-teas-5g… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Re: Responses for LS on "Realization of Ne… Dongjie (Jimmy)
- [Teas] Re: Responses for LS on "Realization of Ne… Julian Lucek
- [Teas] Re: Responses for LS on "Realization of Ne… Dongjie (Jimmy)
- [Teas] Re: Responses for LS on "Realization of Ne… mohamed.boucadair
- [Teas] Last-gasp review of draft-ietf-teas-5g-ns-… Adrian Farrel
- [Teas] Re: Last-gasp review of draft-ietf-teas-5g… Adrian Farrel