Return-Path: 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 855AAC14F6BF; Fri, 27 Sep 2024 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.104 X-Spam-Level: X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk 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 V5I-fqdynZoK; Fri, 27 Sep 2024 11:08:27 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51AAC14F69E; Fri, 27 Sep 2024 11:08:23 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 48RI8Lfq020520; Fri, 27 Sep 2024 19:08:21 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0EF494604B; Fri, 27 Sep 2024 19:08:21 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E29124603D; Fri, 27 Sep 2024 19:08:20 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Fri, 27 Sep 2024 19:08:20 +0100 (BST) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 48RI8KJ1028808 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Sep 2024 19:08:20 +0100 From: "Adrian Farrel" To: References: <762136658.2244950.1727166111240@www.getmymail.co.uk> In-Reply-To: Date: Fri, 27 Sep 2024 19:08:21 +0100 Organization: Old Dog Consulting Message-ID: <01da01db1108$3d1bbc40$b75334c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DB_01DB1110.9EE183D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOj5WB0YUlq6PQXkL1eu8oEVHYtQIES6yVAbVs/M0CdvonTrHTDBGg Content-Language: en-gb X-Originating-IP: 82.69.109.75 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=eR5sgmx4IaoUqUSNIPt6N 9OjZMW7EcXlvViAo3nqSzc=; b=IzCVEpJRJe3QoWa7RWl1chjUf0+kv6tA3wXKu JacPr0habwixEgR3c/PAGr1y2L1Ei+lVGNdkPM6abSPOoWLlfSCoP8hJzVObdAQ0 UcgDomyBKQWNbd/8FCE1F+55XozbkRowTGXr2YazTr7Q6+wDjPnj8QsM9WcU5Xk8 wX0SK16qPaek5hAoLzmCrE5P3J6bTEBIFMFQgs+r8xLYRvIg+oRuP8JBtrHBsiqW F3gzwRwKIRIGbAfzsXXvHl8seuKdgpI5rXhE3g6lLkMFonyG1CZjR+mn1iqrB/IJ Yt92/8Ooe9M6BjzGOnDNH28ZmrPCd8ESpHFakfTkK6CeMMvwg== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003 X-TM-AS-Result: No--29.001-10.0-31-10 X-imss-scan-details: No--29.001-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--29.001000-10.000000 X-TMASE-MatchedRID: hFbMlnd2lLON/VCJeShKRuaJxsdFSxpXcU9StUObqO2vvh7pqacPxlGJ GXffuLdvX6xTdolKeplqC7TQCi+dYlE9hxyXYYwX4zY5wVWr0vWdVNZaI2n6/9SgyJTgyLvlUoT t/30WcdwFTPZD7GmMeL6Wcm8Utozc78zMceB3Yq5hjejNb4SeBxd8ENHLtW0zY/8hgefJn7Avnz au3N9X4JuwtlfShNlWJAx9A0s+9b/b8TWcZn/4QF3vqo4Ydbl4h2VzUlo4HVNPnKxAOPp4WcRaF 1V1c2e/wisnIbO8h0Oipw58JSX3jC+qQ//vmyLqnDDIoDU9AIKIqb8invuVHwTHaede/M0j7/yW j42xgZdDw6V//8M6z9Uh8Vo+5LXyLUq1GVUwshd8uNQieRnOFywjpa51oXxrKQNhMboqZloc5SG KNk1CGwl9IWBxx+kB2uR6RTfmd0HpLYFxODRuvoO2DTkzdUTVh4Ce12gzEFoXjfR3d0weRhY6BY xX8S3/PZ6UAg+Kd2Y6zeu+5r9PtMQ2UcsW8IS3sB2/Q/fV6TPHYNKoSYWoHqwfObg093Ck4Jg2a OOdYIIUXKizhC4rw130ISeaupUH2EApGNUyAJOhezPQ4WaDPot06zoQFEShJScvOTX4jHMsNj/x IgdFO+d8vhGAIlbvVYEdQ4hoU3EvICV5dRzM3BxC8tpxECBwg2tpowTD9Vq/KQGKQH1rQI4YPFy +no7QTbfnCzLYSUi8KZbHAKXdKRf1kL+6Ssg6DtAOZXYRMNzp9R8QuoVQfwibdWzeGzAXFGSctN FNXqpYvDjjgl1U+oDAbaZpdAwgSaVfaxxV94+HH67xJFOT7J4CIKY/Hg3AaZGo0EeYG97UHQeTV DUrIj166Jh7ejx4YseN4aSOH1crN8z0HohG3v558CedkGIvIXptJJqT2TE= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: BXTQGISOFWPK6NK3FL3CEOPO6YCB6TZ2 X-Message-ID-Hash: BXTQGISOFWPK6NK3FL3CEOPO6YCB6TZ2 X-MailFrom: adrian@olddog.co.uk 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 WG Chairs' X-Mailman-Version: 3.3.9rc4 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Responses_for_LS_on_=22Realization_of_Network_Sli?= =?utf-8?q?ces_for_5G_Networks_Using_Current_IP/MPLS_Technologies=22?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_01DB_01DB1110.9EE183D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Sorry, I was slower than I promised. =20 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=E2=80=99ve copied the relevant parts below and added my own comments. =20 Cheers, Adrian =20 > 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. > =20 > [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. > =20 > As for the term =E2=80=9Chand-off=E2=80=9D, 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=E2=80=99d suggest to make it = clear that it is =E2=80=9Cnetwork slice hand-off in data plane=E2=80=9D. > =20 > 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.=20 =20 [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 =20 [Krzysztof] =E2=80=9Chand-off=E2=80=9D is very generic term, used in = many contexts. We clarified the term =E2=80=9Chand-off=E2=80=9D in the = context of this draft, and using it in the similar manner as term = =E2=80=9Chand-off/handoff=E2=80=9D in the = draft-ietf-teas-5g-network-slice-application, for consistency between = two drafts. =20 [Krzysztof] In the context of mapping, this section already references = draft-ietf-teas-5g-network-slice-application (one paragraph earlier).=20 =20 There seems to have been no change for this. That=E2=80=99s 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. =20 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) =3D provider network.=20 But I=E2=80=99m also confused =E2=98=B9 As Krzysztof notes, the previous paragraph, talks about = =E2=80=9Cmapping=E2=80=9D 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 =E2=80=9Chand-off methods = for slice mapping between customer sites and provider networks=E2=80=9D =20 So, my conclusion is that Jie has correctly indicated a point of = ambiguity in the text. It=E2=80=99s 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=E2=80=A6 =20 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 =20 > 782 3.6. First 5G Slice versus Subsequent Slices > =20 > 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. > =20 > [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. > =20 > It is suggested to clarify the presumption of shared slice for control = plane in the beginning of section 3.6. =20 [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 (=E2=80=9CFor instance=E2=80=9D). 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. =20 I think a paragraph has been added to give exactly the clarification Jie = asked for (although I don=E2=80=99t see why the new paragraph is = indented. =20 > 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.=20 > =20 > [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 = =E2=80=9Cadvanced TE techniques, with or without bandwidth = reservation=E2=80=9D. 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 =E2=80=9Ccoarse-grained resource control=E2=80=9D? =20 [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=E2=80=99t gain much attention = among operators (real production network deployments), comparing to = simple per-path BW reservation model. =20 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. =20 Actually, it is possible that there is a little refinement we can do in = this section. The two bullet points talk about =E2=80=9CFine-grained = resource control at the PE=E2=80=9D and =E2=80=9CCoarse-grained resource = control at the transit links,=E2=80=9D while the text that Jie quoted = talks about bandwidth reservation. Additionally, Figure 11 mentions = =E2=80=9Cfine-grained QoS=E2=80=9D and =E2=80=9Ccoarse-grained = QoS=E2=80=9D 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. =20 Can I suggest: OLD with or without bandwidth reservations NEW with or without per-path bandwidth reservations END =20 > 1097 4.2.1. An Example of Local IPv6 Addressing Plan for Network = Functions > =20 > [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. =20 [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. =20 I don=E2=80=99t 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.=20 =20 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 =E2=80=9CAn example of how the S-NSSAI could be encoded = in an IPv6 address is given in Appendix Foo.=E2=80=9D ------=_NextPart_000_01DB_01DB1110.9EE183D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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/ngKXuU= K0nqHq_g5Hok4BVttLML0/

I=E2=80=99ve copied = the relevant parts below and added my own = comments.

 

Cheers,

Adrian

 

> = 177=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3, or Layer 4).=C2=A0 The = realization of the mapping between customer

> = 178=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sites and provider = networks is refered to as the = "hand-off".

> = 179=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 4 lists a set of = such hand-off methods.

>=C2=A0

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

>=C2=A0

> As for = the term =E2=80=9Chand-off=E2=80=9D, 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=E2=80=99d suggest to make it clear = that it is =E2=80=9Cnetwork slice hand-off in data = plane=E2=80=9D.

>=C2=A0

> 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] = =E2=80=9Chand-off=E2=80=9D is very generic term, used in many contexts. = We clarified the term =E2=80=9Chand-off=E2=80=9D in the context of this = draft, and using it in the similar manner as term = =E2=80=9Chand-off/handoff=E2=80=9D 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=E2=80=99s 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) =3D = provider network.

But I=E2=80=99m also = confused =E2=98=B9

=

As Krzysztof notes, = the previous paragraph, talks about =E2=80=9Cmapping=E2=80=9D 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 =E2=80=9Chand-off methods for slice mapping = between customer sites and provider = networks=E2=80=9D

 

So, my conclusion is = that Jie has correctly indicated a point of ambiguity in the text. = It=E2=80=99s 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=E2=80=A6

 

OLD<= /p>

=C2=A0=C2=A0 The 5G = control plane uses the Single Network Slice = Selection

=C2=A0=C2=A0 Assistance = Information (S-NSSAI) for slice identification

=C2=A0=C2=A0 = [TS-23.501].=C2=A0 Because S-NSSAIs are not visible to the = transport

=C2=A0=C2=A0 domain, 5G = domains can expose the 5G slices to the transport = domain

=C2=A0=C2=A0 by mapping = to explicit data plane identifiers (e.g., Layer 2, = Layer

=C2=A0=C2=A0 3, or Layer = 4).=C2=A0 The realization of the mapping between = customer

=C2=A0=C2=A0 sites and = provider networks is refered to as the = "hand-off".

=C2=A0=C2=A0 Section 4 = lists a set of such hand-off methods.

NEW<= /p>

=C2=A0=C2=A0 The 5G = control plane uses the Single Network Slice = Selection

=C2=A0=C2=A0 = Assistance Information (S-NSSAI) for slice = identification

=C2=A0=C2=A0 = [TS-23.501].=C2=A0 Because S-NSSAIs are not visible to the = transport

=C2=A0=C2=A0 domain, = 5G domains can expose the 5G slices to the transport = domain

=C2=A0=C2=A0 by = mapping to explicit data plane identifiers (e.g., Layer 2, = Layer

=C2=A0=C2=A0 3, or = Layer 4).=C2=A0 The realization of the mapping between = slice

=C2=A0=C2=A0 = parameters at customer sites and those in the provider = network

=C2=A0 =C2=A0is = referred to as the "hand-off" between the networks.=C2=A0 = Section 4

=C2=A0 = =C2=A0describes some possible hand-off methods.

END<= /p>

 

> = 782=C2=A0=C2=A0=C2=A0=C2=A0 3.6.=C2=A0 First 5G Slice versus Subsequent = Slices

>=C2=A0

> = 784=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An operational 5G Network = Slice incorporates both 5G control plane

> = 785=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and user plane = capabilities.=C2=A0 For instance, consider a slice based = on

> = 786=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 split-CU in the RAN, both = CU-UP and Centralized Unit Control Plane

> = 787=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (CU-CP) need to be = deployed along with the associated interfaces = E1,

> = 788=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 F1-c, F1-u, N2, and N3 = which are conveyed in the TN.=C2=A0 In this = regard,

> = 789=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the creation of the = "first slice" can be subject to a specific = logic

> = 790=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that does not apply to = subsequent slices.

>=C2=A0

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

>=C2=A0

> 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 = (=E2=80=9CFor instance=E2=80=9D). 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=E2=80=99t see why the new paragraph is = indented.

 

> = 918=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 methods = used here can range from careful network planning, = to

> = 919=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ensure a = more or less equal traffic distribution (i.e., equal = cost

> = 920=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 load = balancing), to advanced TE techniques, with or = without

> = 921=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = bandwidth reservations, to force more consistent load = distribution

> = 922=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 even in = non-ECMP friendly network topologies.

>=C2=A0 =

> [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 =E2=80=9Cadvanced TE techniques, with = or without bandwidth reservation=E2=80=9D. 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 =E2=80=9Ccoarse-grained resource = control=E2=80=9D?

 

[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=E2=80=99t 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 =E2=80=9CFine-grained resource control = at the PE=E2=80=9D and =E2=80=9CCoarse-grained resource control at the = transit links,=E2=80=9D while the text that Jie quoted talks about = bandwidth reservation. Additionally, Figure 11 mentions = =E2=80=9Cfine-grained QoS=E2=80=9D and =E2=80=9Ccoarse-grained = QoS=E2=80=9D 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<= /p>

with or without bandwidth = reservations

NEW<= /p>

with or without = per-path bandwidth reservations

END<= /p>

 

> = 1097=C2=A0=C2=A0=C2=A0 4.2.1.=C2=A0 An Example of Local IPv6 Addressing = Plan for Network Functions

>=C2=A0 =

> [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=E2=80=99t 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 =E2=80=9CAn = example of how the S-NSSAI could be encoded in an IPv6 address is given = in Appendix Foo.=E2=80=9D

------=_NextPart_000_01DB_01DB1110.9EE183D0--