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 AC068C14F60B; Fri, 4 Oct 2024 14:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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_BLOCKED=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 KLnAYt-3WY4X; Fri, 4 Oct 2024 14:25:10 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 396CFC1DFD25; Fri, 4 Oct 2024 14:25:07 -0700 (PDT) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 494LP5Ct027836; Fri, 4 Oct 2024 22:25:05 +0100 Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF71C4604A; Fri, 4 Oct 2024 22:25:04 +0100 (BST) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CF9F746043; Fri, 4 Oct 2024 22:25:04 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Fri, 4 Oct 2024 22:25:04 +0100 (BST) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 494LP4dP002052 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Oct 2024 22:25:04 +0100 From: "Adrian Farrel" To: , "'TEAS WG'" , "'Dongjie \(Jimmy\)'" References: <762136658.2244950.1727166111240@www.getmymail.co.uk> <01fb01db1113$8304c3e0$890e4ba0$@olddog.co.uk> In-Reply-To: Date: Fri, 4 Oct 2024 22:25:04 +0100 Organization: Old Dog Consulting Message-ID: <002001db16a3$e101bf30$a3053d90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01DB16AC.42C89830" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOj5WB0YUlq6PQXkL1eu8oEVHYtQIES6yVAbVs/M0CdvonTgJYHGBAAs27eP+xtWycMA== 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=jx+hLw3obsIu7XHz/tSAG tkCxC0NwQbhvuxKRDu6fLY=; b=o+upfyfPdVPikx/a4Ux/KLW/9+UdHAbvOacjd 6QvjmFT9WfiYgOyBfe5i4mbdflHv04ydX6jH53uYN+rcLNnCtLOhUI03fNMymkff UioyeG+bNMIXMdLtcJhmGeZ/En5eX3YkDcJAXeZr7FD6qY24diq+xx6qTz4xVHKr HKO7LaFcd4g3dT4U6w1+0uifeRM9J4qA6SmpuRLjEt/OkbpjVO+TDTj80U4snWND cM83pQKMPFZx+64AD/Z0yxie9rTz0wqr++giS02UcjwDQuPx7TBxuOVMADz0aT/8 x4F/qtr5s8Lfxlktqmcqcsm7qZifyeMkYc5SCfFhCKdTLGXQQ== 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--32.543-10.0-31-10 X-imss-scan-details: No--32.543-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--32.542900-10.000000 X-TMASE-MatchedRID: y4RwxWhKtOLuYusHgJkgyhK8RjA2ODb7PB3TAsOZaVbodsPZQI651HUa viB0iuYrdEuhQ3Lc1Z16xrk3e4SMnArcxrzwsv5uaEANKbBJN13AuQ0xDMaXkISLmpUqCnJJ1iX n5Tch5mfK+QFXYp+GtXH0SatXLU38uW77/y896shy4VFP6muDhnkCztnOmtvO2d8mtRIRsUNfhK SHUmDj44VOjT1T8KvPy+dduFIbDet7TXnCjI8t9pGAt645FF0SFXXsIV9lgAExGo3N/81UFWN3V ebEPC8I582DxMepztODl9ZlmcT9dt+pUF0HsjxRO8fk7n+zHAzCvo6DOxRiGqAiHx6Ltn6xLn1n 55HeZKp4dPyFNoZcu6qtYDdF/oY9DOs94g784ge/yN2q8U674q56qUPGHxOhRKLa632yXzSh9xN 1JciTvbiYT/2rP2B2dh9gYos97K3x3wBl+NfLJH5Lmbb/xUuaTGgmdNvqkl9T/LdWx/Pp4avWMq bRJSuXKyxf23FIZ5E6Vyyhf+5DyINraaMEw/VaRYYm6fbhZvVEtBaWyPteE8Qa1++oHl5UsdNam b+C3MnZdCBgFYTw+idGVmAxpcVFmqdQuKXkmov2cu1DXV6sTiQ9RpUKMagatY4N1nU8OYSHcB9/ Of2iDweWR71HtRmwjjfhmqTuNr2Hdk37mUVHt1Ib54YgVY/WjlXUAIjJm2f5N6bApqr+07buIiM UvRcUoOO+fZ5MzqrLZsmxtv0WqmJm48TWP3hg8sIvtOod4gDltPc+6y6OTPMn7cvpa3NIA/zfon Vtuo8D4OR168fej+GaAd2t6Be1oow1ZluG4awh+cXdVp/Twpsoi2XrUn/JlR1cT9YafQV95l0nV eyiuFXnPmsAbW9lP53QJZ1qXGNKdDgyPBo716sQd9qPXhnJ/4rWvpj9UcgD/dHyT/Xh7Q== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: DWAVMBHF66RN3SSYMMG4UTFOUW3V4I2V X-Message-ID-Hash: DWAVMBHF66RN3SSYMMG4UTFOUW3V4I2V 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 Chairs' X-Mailman-Version: 3.3.9rc5 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Last-gasp_review_of_draft-ietf-teas-5g-ns-ip-mpls?= =?utf-8?q?-11?= 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_0021_01DB16AC.42C89830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, Absent any follow-up by Monday, we will proceed with the publication of the candidate version shared earlier. Posting new versions is always a good idea. A diff to track the changes made so far can be seen here: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-teas-5g-ns-ip-mpls &url_2=https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-n s-ip-mpls.txt. [AF] Diff looks good. But two new nits. 3.4.2 now seems to have... This document focuses on RFC9543 9543 Network Slice deployments where Just after Figure 16 s/(e.g., no LDP, RSVP, and SR)./ (e.g., no LDP, RSVP, or SR)./ Please see inline. Yes. idnits shows " Unused Reference: 'TR-GSTR-TN5G' " [Med] Argh. Fixed. Thanks. --- Section 2, having said the document makes use of the terms defined in RFC 9543, proceeds to provide a new definition of "customer" and "provider". I wonder whether those new definitions are necessary, and if they are I think great care is needed to achieve disambiguation. [Med] Section 2 also says right after the ref to 9543: "See Section 3.3 for the contextualization of some of these terms." We used to have "customer" and "provider" entries be part of 3.3 but we moved them here because we received a comment to group all defs. [AF] OK. *If* you must have definitions of customer and provider that differs from what is in 9543, then including the definitions in Section 2 is the right thing to do. I think, in that case, the forward reference to 3.3 is fine. But, your definition of customer *is* different from the definition in 9543. You call out that this is different from a 5G customer by saying "This entity is distinct from the customer of a 5G Network Slice Service." But you don't note the difference from 9543. I am unable to tell whether this is a scoping difference (yours is a subset of the 9543 definition), or something different. I don't really find 3.3 clarifies this, and I think that, given the statement that this document uses the terms defined in 9543, you need some explanation. For example, you might say "In the context of this document, this definition replaces the one found in RFC 9543," or whatever is appropriate. The definition of provider seems to be much closer to that in 9543. Close enough that I wonder why you need is. In Section 3.1, piping ("|") is used to indicated quoted text from 3GGPP documents. That's good. But: - It is probably de trop to use quotation marks as well. [Med] "" were used to ease demux the quotation from the source. - It appears as though the reference is part of the quote. [Med] moved the source refs to be positioned before the citation and removed the redundant "". --- 3.2.1 Ditto the use of | and " [Med] Fixed. --- 3.2.2 I don't object to one word of the text in 3.2.2. I do find it peculiar that, while 3.2.1 is nicely quoted from 3GPP documentation, the text in this section is longer and un-cited. I should imagine that the paragraph... The objective of Transport Network Slicing is ...should be founded in a 3GPP definition. [Med] We can't formally cite any reference here where the exact words are used. The definition inspires from 3GPP docs, especially from the following: "When providing an end to end communication service, the network may use non-3GPP parts (e.g. Data centre network (DCN), Transport network (TN)) in addition to the network components defined in 3GPP. Therefore, in order to ensure the performance of a communication service according to the business requirements, the 3GPP management system has to coordinate with the management systems of the non-3GPP parts (e.g., MANO system) when preparing a network slice for this service. This coordination may include obtaining capabilities of the non-3GPP parts and providing the slice specific requirements and other requirements on the non-3GPP parts. Figure 4.7.1 illustrates an example for the coordination with management of TN part (e.g., directly or via MANO system)." + (extract of TN specific objectives) "The network slice related requirements include requirements such as: area traffic capacity, charging, coverage area, degree of isolation, end-to-end latency, mobility, overall user density, priority, service availability, service reliability, UE speed." While the first half of the paragraph... Transport Network Slicing provides various degrees of sharing of resources between slices ...presumably stems from 9543 [Med] We can cite Section 8 of 9543. [AF] Nice The rest of the text is explanatory in the context of this document (and maybe should say so). [Med] Added the following NEW: "The following further elaborates on how Transport Network Slicing is defined in the context of this document." [AF] That's helpful. I wonder whether, in view of your statement that, "The definition inspires from 3GPP docs," you might include some such statement with references to the two documents you quoted from. Thus... The following further elaborates on how Transport Network Slicing is defined in the context of this document. It draws on the 3GPP definition of Transport Network Slicing as described in [ref] and [ref]. --- Slice scopes and SDP locations. It is all really confusing to me, and I do not arrive at anything other than contradictions from the text :-( Figure 1 shows the TN slice and also shows the type 3 and type 4 SDP locations. [Med] These SDPs for "RFC 9543 Network Slice", not the full TN slice. We have the following in the introduction: Specifically, this document describes an approach to how RFC 9543 Network Slices are realized within provider networks and how such slices are stitched to Transport Network resources in a customer site in the context of Transport Network Slices (Figure 1). Concretely, the realization of an RFC 9543 Network Slice (i.e., connectivity with performance commitments) involves the provider network and partially the AC (the PE-side of the AC). This document assumes that the customer site infrastructure is over-provisioned and involves short distances (low latency) where basic QoS/scheduling logic is sufficient to comply with the Service Level Objectives (SLOs). But, an SDP is the point at which the slice service begins or ends. It is the edge of the slice. Either: - You are saying that a transport slice does not map perfectly to an IETF slice Or: - There is something wrong with this and the text in 3.4.2. I don't think any of this changes any of the technical details or practicalities of the solutions described. It just that the description seems plain wrong. For example, where you talk about mapping service parameters: where is that mapping performed? The question, I suppose is, are you constructing a TN slice that encompasses network resources that are both IETF and non-IETF. In that case, the service parameters are mapped at the edge of the TN slice, and then they are mapped again at the network boundary at the start of the IETF technology. If your intention is that the TN slice is constructed from elements of the customer domain (possibly non-IETF) and the provider domain (IETF), that would be fine, but I think the TN slice end points are still the SDPs. If, conversely, you are saying that the TN slice is a composite of customer domain slice and IETF slice, then you have the SDPs correctly placed, but you have not made this composite clear. [Med] 3.4.1 says: A TN slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in Section 3.4.2. A TN slice might be considered as a variant of horizontal composition of Network Slices mentioned in Appendix A.6 of [RFC9543]. [AF] Yeah OK. And I see para 2 of the Introduction does say this. Maybe it is clear enough. I'm not sure why it escaped me on first (or even nth) reading. Maybe the only thing I am left with is to be careful all the way through that when you talk about a network slice, we need to be clear whether you are talking about the end-to-end (composed) TN slice, or just the 9543 slice. Perhaps worth a quick re-read to see whether there remains any ambiguity. [Med] Updated 3.4.2 to remind that this is about 9543 network slice deployments. It does not help that 3.4.2 goes on to say: The concept of distributed PE (Section 3.3.4) assimilates CE-based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as SDP Type 3 or 4 in this document. The problem is not with the text, but with the fact that your Figure 6 shows the TN slice extending to the CEs in a model where the CEs are distinct from the PEs. (To me it seems that you are doing types 1 and 2 in this document with the case of distributed PE assimilating types 3 and 4.) I start to run into some of this again in Section 4. For example, in 4.1 In this option, the RFC 9543 Network Slice, fulfilling connectivity requirements between NFs that belong to a 5G slice, is represented at an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in Figure 12. That suggests to me that the model in your head is that the VLAN ID is indicative of either: - onto which IETF slice the SDP should place the traffic (the traffic is at that stage not yet sliced only marked for slicing) or: - on which IETF slice the traffic is flowing (the traffic has already been sliced and the SDP is actually at the end of the TN slice). To complete my whining about this, 4.2 shows the "tunnels representing slices" as extending all the way to the NFs (CEs not marked). Surely, in that case, the SDP is at the end of the tunnel? I'd be quite happy with either or any approach. I just want the description to match. --- 3.6 At the time of writing (2024), Section 6.1.2 of [NG.113] specifies Well... NG.113 is a dated reference. Doesn't that mean that you can simply say Section 6.1.2 of [NG.113] specifies While it is true that 3GGP's "5GS Roaming Guidelines" may change over time. The referenced Version 4 dated 2021 will not change. [Med] Fixed. --- 3.7 s/of [RFC9522])./of [RFC9522]./ [Med] Fixed. Thanks. --- Figure 11 Is there an arrow head missing from the left hand end of the line within the right hand P node? [Med] Thanks for catching this. There was a missing +. [AF] Yeah, you caught something I missed (in the right hand PE a missing +), but have not fixed the thing I mentioned (in the right hand P missing a <). The line should read == == | +---->o<----->o<--->o<------>o<--->o<----->o<----+ | ------=_NextPart_000_0021_01DB16AC.42C89830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Med,

 

Absent any follow-up by Monday, we will = proceed with the publication of the candidate version shared = earlier.

 

Posting new versions is = always a good idea.

=

 

A diff to = track the changes made so far can be seen here: https://author-tools.ietf.org/api/id= diff?doc_1=3Ddraft-ietf-teas-5g-ns-ip-mpls&url_2=3Dhttps://boucadair.= github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.txt.

 

[AF] Diff looks good. = But two new nits…

 

3.4.2 now seems to = have...

   This document focuses on RFC9543 = 9543 Network Slice deployments where

 

Just after Figure = 16

s/(e.g., no LDP, RSVP, and SR)./ (e.g., no LDP, = RSVP, or SR)./

 

Please see inline. =

 

Yes…<= /span>

 

idnits shows " Unused = Reference: 'TR-GSTR-TN5G' "

 

[Med] Argh. Fixed. = Thanks.

 

---

 

Section 2, = having said the document makes use of the terms defined = in

RFC 9543, proceeds to provide a new = definition of "customer" and

"provider". I wonder = whether those new definitions are necessary, and =

if they are I think great care is = needed to achieve disambiguation.

 

[Med] Section 2 also says right after = the ref to 9543: “See = Section 3.3 for the contextualization of some of these = terms.”

 

We used = to have “customer” and “provider” entries be = part of 3.3 but we moved them here because we received a comment to = group all defs.

 

[AF] OK. *If* you = must have definitions of customer and provider that differs from what is = in 9543, then including the definitions in Section 2 is the right thing = to do. I think, in that case, the forward reference to 3.3 is = fine.

 

But, your definition = of customer *is* different from the definition in 9543. You call out = that this is different from a 5G customer by saying "This entity is = distinct from the customer of a 5G Network Slice Service." But you = don't note the difference from 9543.

 

I am unable to tell = whether this is a scoping difference (yours is a subset of the 9543 = definition), or something different. I don't really find 3.3 clarifies = this, and I think that, given the statement that this document uses the = terms defined in 9543, you need some explanation. For example, you might = say "In the context of this document, this definition replaces the = one found in RFC 9543," or whatever is = appropriate.

 

The definition of = provider seems to be much closer to that in 9543. Close enough that I = wonder why you need is.

 

In Section 3.1, piping = ("|") is used to indicated quoted text from = 3GGPP

documents. That's = good.

But:

- It is = probably de trop to use quotation marks as well.

[Med] “” were used to ease = demux the quotation from the source.

- It = appears as though the reference is part of the = quote.

 

[Med] moved the source refs to be = positioned before the citation and removed the redundant = “”.

---

 

3.2.1

 

Ditto the = use of | and "

[Med] Fixed.

 

---

3.2.2

 

I don't = object to one word of the text in 3.2.2. I do find it = peculiar

that, while 3.2.1 is nicely quoted = from 3GPP documentation, the text in

this = section is longer and un-cited.

 

I should = imagine that the paragraph...

    The objective of = Transport Network Slicing is

...should = be founded in a 3GPP definition.

 

[Med] We can’t formally cite any = reference here where the exact words are used. The definition inspires = from 3GPP docs, especially from the following: =

 

“When providing an end to end = communication service, the network may use non-3GPP parts (e.g. Data = centre network (DCN), Transport network (TN)) in addition to the network = components defined in 3GPP. Therefore, in order to ensure the = performance of a communication service according to the business = requirements, the 3GPP management system has to coordinate with the = management systems of the non-3GPP parts (e.g., MANO system) when = preparing a network slice for this service. This coordination may = include obtaining capabilities of the non-3GPP parts and providing the = slice specific requirements and other requirements on the non-3GPP = parts. Figure 4.7.1 illustrates an example for the coordination with = management of TN part (e.g., directly or via MANO = system).”

 

+ (extract of TN specific = objectives)

 

“The network slice related = requirements include requirements such as: area traffic capacity, = charging, coverage area, degree of isolation, end-to-end latency, = mobility, overall user density, priority, service availability, service = reliability, UE speed.”

 

While the = first half of the paragraph...

   Transport Network = Slicing provides various degrees of sharing of

   resources between = slices

...presumably stems from = 9543

 

[Med] We can cite Section 8 of = 9543.

 

[AF] = Nice

 

The rest of = the text is explanatory in the context of this document = (and

maybe should say = so).

 

[Med] Added the following = NEW:

 

“The following further elaborates = on how Transport Network Slicing is

defined in the context of this = document.”

 

[AF] That's = helpful.

 

I wonder whether, in = view of your statement that, "The definition inspires from 3GPP = docs," you might include some such statement with references to the = two documents you quoted from. Thus...

 

   The = following further elaborates on how Transport Network Slicing = is

   defined in the context of this = document. It draws on the 3GPP definition

   of = Transport Network Slicing as described in [ref] and = [ref].

 

---

 

Slice = scopes and SDP locations.

 

It is all = really confusing to me, and I do not arrive at anything = other

than contradictions from the text = :-(

 

Figure 1 = shows the TN slice and also shows the type 3 and type 4 = SDP

locations.

[Med] These SDPs for “RFC 9543 = Network Slice”, not the full TN slice. We have the following in = the introduction:

 

   Specifically, this = document describes an approach to

   how RFC 9543 Network = Slices are realized within provider networks and

   how such slices are = stitched to Transport Network resources in a

   customer site in the = context of Transport Network Slices (Figure 1).

   Concretely, the = realization of an RFC 9543 Network Slice (i.e.,

   connectivity with = performance commitments) involves the provider

   network and partially the = AC (the PE-side of the AC).  This document

   assumes that the customer = site infrastructure is over-provisioned and

   involves short distances = (low latency) where basic QoS/scheduling

   logic is sufficient to = comply with the Service Level Objectives

   = (SLOs).

 

But, an SDP = is the point at which the slice service begins or ends. = It

is the edge of the = slice.

 

Either:

- You are = saying that a transport slice does not map perfectly to = an

  IETF = slice

Or:

- There is = something wrong with this and the text in 3.4.2.

 

I don't = think any of this changes any of the technical details = or

practicalities of the solutions = described. It just that the description

seems plain = wrong.

 

For = example, where you talk about mapping service parameters: = where

is that mapping performed? The = question, I suppose is, are you

constructing a TN slice that = encompasses network resources that are

both IETF = and non-IETF. In that case, the service parameters = are

mapped at the edge of the TN slice, = and then they are mapped again

at the = network boundary at the start of the IETF = technology.

 

If your = intention is that the TN slice is constructed from elements = of

the customer domain (possibly = non-IETF) and the provider domain (IETF),

that would = be fine, but I think the TN slice end points are still the =

SDPs.

 

If, = conversely, you are saying that the TN slice is a composite = of

customer domain slice and IETF = slice, then you have the SDPs correctly

placed, but = you have not made this composite clear.

 

[Med] 3.4.1 says: =

 

   A TN slice relies upon = resources that can involve both the provider

   and customer TN = domains.  More details are provided in Section = 3.4.2.

 

   A TN slice might be = considered as a variant of horizontal = composition

    of Network Slices = mentioned in Appendix A.6 of [RFC9543].

 

[AF] Yeah OK. And I = see para 2 of the Introduction does say this. Maybe it is clear enough. =

I’m not sure = why it escaped me on first (or even nth) = reading.

 

Maybe the only thing = I am left with is to be careful all the way through that when you talk = about a network slice, we need to be clear whether you are talking about = the end-to-end (composed) TN slice, or just the 9543 slice. Perhaps = worth a quick re-read to see whether there remains any = ambiguity.

 

[Med] Updated 3.4.2 to remind that this = is about 9543 network slice deployments.

 

It does not = help that 3.4.2 goes on to say:

   The concept of = distributed PE (Section 3.3.4) assimilates = CE-based

   SDPs defined in = Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as = SDP

   Type 3 or 4 in this = document.

 

The problem = is not with the text, but with the fact that your Figure = 6

shows the TN slice extending to the = CEs in a model where the CEs are

distinct = from the PEs. (To me it seems that you are doing types 1 and = 2

in this document with the case of = distributed PE assimilating types 3

and = 4.)

 

I start to = run into some of this again in Section 4. For example, in = 4.1

   In this option, the = RFC 9543 Network Slice, fulfilling connectivity

   requirements between = NFs that belong to a 5G slice, is represented at

   an SDP by a VLAN ID = (or double VLAN IDs, commonly known as QinQ), as

   depicted in Figure = 12.

That suggests to me that the model = in your head is that the VLAN ID is

indicative = of either:

- onto which IETF slice the SDP = should place the traffic (the traffic

  is at that stage not = yet sliced only marked for slicing)

or:

- on which = IETF slice the traffic is flowing (the traffic has = already

  been sliced and the SDP is = actually at the end of the TN slice).

 

To complete = my whining about this, 4.2 shows the "tunnels = representing

slices" as extending all the = way to the NFs (CEs not marked). Surely,

in that = case, the SDP is at the end of the tunnel?

 

I'd be = quite happy with either or any approach. I just want the =

description to = match.

 

---

 

3.6

 

   At the time of writing = (2024), Section 6.1.2 of [NG.113] specifies

 

Well...

NG.113 is a = dated reference. Doesn't that mean that you can simply = say

 

   Section 6.1.2 of = [NG.113] specifies

 

While it is = true that 3GGP's "5GS Roaming Guidelines" may change = over

time. The referenced Version 4 = dated 2021 will not change.

 

[Med] Fixed.

---

 

3.7

 

s/of = [RFC9522])./of [RFC9522]./

[Med] Fixed. = Thanks.

 

---

 

Figure = 11

 

Is there an = arrow head missing from the left hand end of the line = within

the right hand P = node?

[Med] = Thanks for catching this. There was a missing = +.

 

[AF] Yeah, you caught = something I missed (in the right hand PE a missing +), but have not = fixed the thing I mentioned (in the right hand P missing a = <).

The line should = read

=3D=3D =3D=3D = |    = +---->o<----->o<--->o<------>o<--->o<-----&= gt;o<----+    = |

------=_NextPart_000_0021_01DB16AC.42C89830--