Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06
Adrian Farrel <adrian@olddog.co.uk> Wed, 19 April 2023 21:32 UTC
Return-Path: <adrian@olddog.co.uk>
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 95E52C13737C for <teas@ietfa.amsl.com>; Wed, 19 Apr 2023 14:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level:
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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_NONE=0.001, 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=fail (2048-bit key) reason="fail (message has been altered)" 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 8HsR-_WS1xdr for <teas@ietfa.amsl.com>; Wed, 19 Apr 2023 14:32:32 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AF3C13AE43 for <teas@ietf.org>; Wed, 19 Apr 2023 14:32:31 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 33JLWTDk029009; Wed, 19 Apr 2023 22:32:29 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 326154604B; Wed, 19 Apr 2023 22:32:29 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 129A54604A; Wed, 19 Apr 2023 22:32:29 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 19 Apr 2023 22:32:29 +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 33JLWSu4006924 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2023 22:32:28 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>
Cc: 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>, 'TEAS WG' <teas@ietf.org>
References: <PAXPR06MB7872C13D819D9FA23362E06CFD929@PAXPR06MB7872.eurprd06.prod.outlook.com> <0ded01d9692e$22695200$673bf600$@olddog.co.uk> <E9C039B8-4EC4-4D06-9508-74956C4418CD@juniper.net>
In-Reply-To: <E9C039B8-4EC4-4D06-9508-74956C4418CD@juniper.net>
Date: Wed, 19 Apr 2023 22:32:28 +0100
Organization: Old Dog Consulting
Message-ID: <046d01d97306$70ec1b60$52c45220$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_046E_01D9730E.D2BC9150"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQCMm9hBH7SB707jAIBuC1pmAfwMBgG+AvefAn0cQu6xqtm1gA==
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=baPqCbyYdhWH/NCasDpJQ nWuFTpIaZuLFDWgQ7b1CnQ=; b=ISu9jdf9WS4JOjPqDmbnuMgeu14vQXN5lWraz syz9yyEjawjNfvaazfY1FQ03eB8qvZnutZjTDzUbNvKVGdipoF1wN3lAk50WWjIa Kv68JoHDAO7NjjmmDCA46Ca9ZOTANlGS4PCqAqstpKTXoiyyQCGY0pJoRlcG4KL5 VWHRyeXUD0v0XTF/i/PTDUmva6lOgq/HFkBAhOvZIbrXBSqat/SxkB/3+qyV0Qab NgKB4vqU0mOLpYL785Idmj+5JFtZtKqX+yjqKXA2liSTKRRlhkeazcg/SYDjYQRe Hs/10ZUj0lKgTs3ncYIVo38xlZ4qp761Yz0l5feo7ky31vYkQ==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27576.003
X-TM-AS-Result: No--21.864-10.0-31-10
X-imss-scan-details: No--21.864-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27576.003
X-TMASE-Result: 10--21.864300-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbI61Z+HJnvsOW9DGjPU7rM+qvcIF1TcLYES3 N7Ud/ZNyMGibEZ740LlvRxdoobG+BG9HrF8i9tDQ1l+BjLM8lsppeZ1cXZibxzE3sIzY2XPPLHX czntTI5xc9vlTL5EiyC97Z1BRZ+RO8lboxuXXyrNswYo64ufkVZnaxzJFBx6vd3XtjqAaoMLv5t G5qQwjQPF6NzSl6coX4EtpiD9zYo0cQvLacRAgcN+Hu92fak/rcV3n4J/0zUMZ9O8/hC7KBkn0v jeeb/bZoEB1tjpzUFuq83teCvB/U4MwY/QOsLdiGqSG/c50XgMUns+AEn7rqVKFxY7/zfGi2Huw 61jLswD3pb5hxMuPbn5YIdOqveFBuII/lqBLVHGXVXMu1aPavPZbeAQELiBUgSQ4PtUR2UT0rvl y3+tbx0GQZ//aWvJv8uPo8sKmXzEg8r4FWHZVi4ipvyKe+5UfNroBpCbt+GamOWRsO8Mnh87Fl0 igGfZUxr19KNKP9wc3YrXE1G+rbbvGEmcXHXAmAjqAxuWkdTEBqNb4Qv6Vo656qUPGHxOhBoOU0 pLm5xgKO0eM7yB2CYKFg1dhciQdmDcRJzGLWpK09h+AUneRjxA5wxKjT3bqoGN51gfb0PDI50/s y1jrGavWMqbRJSuXuvdPeYtG4PLuha5ro/3Uo5eZUDMyphfSyi3S0YyyoadncSzHLoRamUB32yn v+GCSDYwJ4IWQCMgQS6J7Dprc4qHtRd4v4efm4eLB/YGE+cbzZKDA1/pIrntzXL7lPwD/5sc/I6 vXY93WPKk1jTC1pp6A9LWVluBjs4ry6yQggpueAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7up8Odl1VwpCSUTGVAhB5EbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/hQNsSWLJA5hdr8vHFkQpbpKlxzk>
Subject: Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2023 21:32:37 -0000
Hi Krzysztof, Thanks for all of the work. > We just punished updated (v-07) draft. Yeah, I know. It deserved it. :-) I think, given the scale of the changes, the draft deserves a full top-to-bottom reading. I’ll put that on my list. I’ll cut straight to -08. In the meantime, thanks for the detailed responses. A few additional comment in line. See [af]. Best, Adrian From: Krzysztof Szarkowicz <kszarkowicz@juniper.net> Sent: 19 April 2023 12:25 To: adrian@olddog.co.uk Cc: Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>; TEAS WG <teas@ietf.org> Subject: Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06 Hi, I am answering on behalf of co-authors. Many thanks for taking the time to read the draft and provide detailed comments, we really appreciate it. We have gone through them and have comments/made changes as described in-line below. We were actually already involved in a major change for section 3, which concentrates a lot of the comments. We just punished updated (v-07) draft. Please seems well inline for more details [srld]. Best regards, Krzysztof On 2023 -Apr-07, at 10:51, Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > wrote: Hi Oscar, all, I’ve read this draft as part of the adoption poll, and I attach some comments. My current view is that, while the topic covered by the title of the draft is important and should be worked on within the working group, this document is not ready for adoption. I set out my reasons below, and also provide some detailed review comments: most of the detailed minor comments and nits could wait until after adoption, but the major issues form part of my reservations about adopting the current revision. Thanks, Adrian === My take-away from this document is that it does three things: - Describes 5G end-to-end network slices and their component parts - Describes the general mapping and connections when 5G slices utilise IETF transport slices - Talks about specifics of using existing IP/MPLS (and SR) techniques to realise IETF transport slices and stitch them into e2e slices I think a good chunk of the description of 5G slices has been moved to Appendix B, but there is still a lot of text in the document explaining 5G slices. I’m wary of us “interpreting” 3gpp specifications and technologies. I think all of that material does not belong in an IETF document (even an appendix of an informational one). If the 3gpp documents are lacking then the place to fix them is in that body, but if they are not deficient then we can just reference them and move on. [srld] We did mean to interpret 3GPP specifications and technologies – and we agree that we must minimize the 3GPP stickyness. We’re making a few changes (see next comments). However, we want to set the context, so the draft references the 3GPP specification, and discusses how 5G slices could be mapped to slices in transport network (TN) domain. Indeed, our discussions with various stakeholders both from IETF and 3GPP/O-RAN showed that there is a lot of confusion on both sides and we want to bring some clarity (e.g. , an IETF guy will say “network slicing is just a VRF + Traffic Engineering + QoS”, while a 3GPP guy will say “network slicing does not involve TN”). In practice, the Transport domain is out of scope for 3GPP (only RAN and CN domains are in 3GPP scope), and the best place to describe transport aspect of overall 5G slicing architecture (RAN + TN + CN) is IETF. The draft doesn’t touch RAN or CN slicing. Additionally, we can use the principle here for non 5G use cases. [af] Well, I see where you are coming from. Still not sure I like it. You are, of course, right that the TN and its slicing are out of scope of 3GPP, and that’s fine. But the interpretation of e2e slicing is theirs, and we should not put words into their mouths. As a compromise I think we might try to shape the text as “the IETF view of 3GPP slicing” so that we cannot be accused of specifying something that belongs with another SDO. But at the same time, we might try to reduce the material that is explaining the details of 3gpp stuff: I do agree with you that some of this material is missing and needs to be written up somewhere, but I don’t agree that it should be in an Internet-Draft (well, you could try the Independent Submissions Stream). I’ll look at this again in my re-review and see if any suggestions jump out. It seems to me that the general mapping discussion is applicable to any IETF technology (present or future). We already have a draft that we have just finished polling for adoption (draft-gcdrb-teas-5g-network-slice-application with some of the same authors) that covers much of the common ground about the general mapping. It would be good to contain that material in a single document, and I would suggest working to move the relevant material to draft-gcdrb-teas-5g-network-slice-application. That is not to detract from the text in this document that describes the general mapping, just to say we don’t need it in two places. [srld] Agree, this is applicable to any IETF technology. We should discuss how to address the potential overlap with gcdrb. [af] It feels to me like, as I said above, that we can move material into gcdrb. An alternative, as I discussed with Julian at IETF 115, is to create a third draft to contain all the common ground and leave srld and gcdrb to handle the technology-specific parts. Would be happy to hear any firm plans. The discussion of using existing IP/MPLS technology to provide support for end-to-end 5G slicing (sections 4 and 7) is practical and would make a useful document. However, if/when this draft is adopted, can we please sort out a couple of things before the -00 version of the WG draft is posted? 1. I am having a hard time believing that the people named on the front page wrote considerable parts of the text. Are they really all co-authors? Are they even Contributors? Let’s please get out of the habit of “signing up to show our support” – it’s a poor idea that devalues the work and damages the reputation of the people named. And, anyway, could the chairs please make it easy for us to know who is holding the pen as the draft moves forward (presumably Krzysztof and Richard?). [srld] Ack. We just posted the next version of draft with the list of authors trimmed to 5 persons. [af] OK 2. Embedding SVG figures is, of course, allowed. But was it really necessary? I’m pretty sure all of your figures are only SVG versions of ASCII art, anyway. (Why do I care? Can’t be read by an ASCII editor. Makes for nonsense XML.) [srld] Indeed. The source of figures is character/text based (Unicode - what did we use specifically, worth mentioning as they are nicer than vanilla ASCII), and we were experimenting with rendering as SVG for html display. We just posted a new version off the draft with only character (Unicode) based figure. [af] It’s a bit of a “whatever” for me. Since you didn’t submit the XML this time around I can’t look at that. But the text file of -08 completely mangles the figures in a raw ASCII editor. ==Questions== {srld] We have recently completely reworked section 2 and 3 (see draft v-07). Many of your comments seem to be addressed in the latest revision. We hope, most of your comments related to section 3 below are addressed in the updated draft version. Note that this is a major change: the definition of TN is changed to the abstraction of the NF-NF datapath and we’re aligning to PE/CE/AC terminology (I.e. in line with framework and industry semantic). Tbh, we were not happy with the concept of ETN / Segments, while in parallel we were seeing gaps wrt framework for PE/CE/AC starting with the managed CE. In the new version, we chose to rely on distributed CE/PE to converge to a reference design. [af] OK, I’ll pick this up in my re-review. Except, if you are seeing gaps in the framework, why aren’t you raising them either as points of discussion or as specific fixes to the framework? 3.1 has (my emphasis) The objective of 5G Network Slicing is to provide *dedicated* resources of the whole 5G infrastructure to some users/customers, applications, or Public Land Mobile Networks (PLMNs) (e.g., RAN sharing). These resources are from the Transport Network (TN), RAN, and Core Network Functions and the underlying infrastructure. You immediately go on to say (of the NSS) [TS-28.530] defines 5G Network Slicing by introducing the concept of Network Slice Subnet (NSS) to represent slices within each of these domains: RAN, CN, and TN (i.e., RAN NSS, CN NSS, and TN NSS). As per 3GPP specifications, an NSS can be shared or dedicated to a single slice. So, are the resources dedicated or can they be shared? At the least, one of these paragraphs is unclear. [srld] ack - We have simply removed the ref to TS 28.530 / NSS. This does not bring any value while it will create problems. 3GPP folks will argue (and they’re right) that the NSS is actually much more than that: this is a way to group managed objects in a same domain – slicing as we understand it is just an application -. + Generally, discussion around dedicated and shared is a pain: the infra is -almost -always shared. We agree, this needs rewriting – we can discuss that together -. A slice can have dedicated resource (but it can be best effort too), and once you have a slice you can share this slice resource to a set of customers – so the dedicated resource is shared... Confusing, certainly. ==Major== 3.2.1 There seems to be some disagreement between your definitions of TN Segment and Local Segment. If the TN Segment provides connectivity between two sites that host NFs, then the possibility of a Local Segment that connects an NF to the TN seems strange. It is only with your later definition of a site (and having had a conversation with Krzysztof) that this becomes a little clearer to me. (BTW in Figure 2 you have “5G site” not “site” making it appear that there are two different things.) I think the problem stems from the text in 3.2 where you describe what 3gpp means by TN, and then say “but when we say TN we mean only that bit of the TN controlled by the TN operator.” I think this is why you go on to talk about segments in 3.2.1, and perhaps if in 3.2 you had This document defines the Transport Network Segment (see Section 3.2.1) as that part of the TN slice with a service provider scope. That is, the TN Segment extends up to the PE, or the CE if it is also managed by the service provider. The TN Segment may be combined with other segments (Local Segments) to achieve NF-to-NF TN slices. To complement this, Figure 1 might usefully show the whole, composed, TN slice. (Noting that Figure 1 falls into the trap of showing the “Transport Network” as something different to that described by 3gpp. You may mean the “service provider’s network.” This last point is also found in the subsequent paragraph: . In such a case, there is no TN Segment (i.e., no Transport Network Node is present in the datapath). I think, per 3gpp, there may be transport network nodes, but they are not service provider nodes. For what it is worth, you may find the composed network slice draft useful both for terminology and as a reference to help explain composing an end-to-end slice from multiple slice segments. [srld] Yeah agree with most comments, we actually had been rewriting this part for some time. Anyway the relationship between 3GPP and TN is a complicated story. See v-07 of the draft. -- Section 5 seems a lot. It’s not my area of expertise, but it seems like a very large amount of material to describe how to map a RAN slice to a transport slice. [srld] Well, this draft describes concrete realization, including QoS, policers, shapers, traffic classes, traffic engineering, etc., hence this section has details of it. ==Minor== Section 2 Edge Transport Node (ETN): Node, under the transport domain orchestration, that stitches the transport domain to an adjacent domain (e.g., enterprise network, data center, peer provider network). An ETN can be be a Provider Edge (PE) or a managed Customer Equipment (CE). When you say “under transport domain orchestration” I guess you mean “wholly or partially”. That would allow for a number of other scenarios including a slice that terminates at an SDP within a CE, but where the whole CE is not under management control of the transport network operator. I suspect there are also cases where the SDP is in the CE and the CE is not managed in any part by the transport operator. Reading further, in 3.2.1, I wondered by you needed to introduce the term ETN. Of course, you are welcome to, but does it help? You say the ETN is the node that stiches together the Local Segments and TN Segments. You further note that depending on the design, the placement of the SDP may or may not be enforced on the ETN itself. I don’t see how that has meaning! The slice goes as far as the SDP, so if you want to stich the slice to something else, you must do it at the SDP. Thus, in your terminology, the ETN must contain the SDP. (This is why I don’t think the ETN is a useful term, and you should just talk about stitching at the SDP. You may want to limit your realisation to specific placements of the SDP, and that would be fine.) [srld] We have recently completely reworked section 2 and 3 (see v-07 of the draft) We hope, most of your comments related to section 3 are addressed in the updated draft version. -- 3.2 Additionally, we assume that the Transport Network is IP, MPLS, or SRv6 capable. This is OK, but you need to square it with the document title and say it in the Abstract and Introduction. [srld] OK -- 3.2.1 You say... We consider Local Segments as an extension of the connectivity of the RAN/CN domain without slice-specific performances requirements by assuming that the local infrastructure is overprovisioned and implements traditional QoS/Scheduling logic. Why do you do this? I understand that, in this document, you do not want to consider slicing in the site network. And I can see how that is not relevant to your deployments. But there are several problems with your considerations and assumptions that rule out many deployments based on the TN segment realisation you describe. Not least of these is the case where the site is not part of the RAN or CN but supports access to the NFs. Why don’t you just put “the management and deployment of local segments is out of scope of this document.” [srld] the updated has a better scope for the segmentation (we actually used “section” instead of segment since someone told us that SR folks may react). We have a customer site segment which is indeed of out of scope (and that’s metnionned – we will check) -- Figure 3 has a number of cases with a PE, but no CE. Feels a bit odd. [srld] We have recently completely reworked section 2 and 3 (see v-07 of the draft) We hope, most of your comments related to section 3 are addressed in the updated draft version. -- 3.2.2 Figure 4 is a basic example of a Layer 3 CE-PE link realization with shared network resources, such as VLAN-ID and IP prefixes, which must be passed between Orchestrators via the Network Slice Service Interface ([I-D.ietf-teas-ietf-network-slice-nbi-yang]) or an Attachement Circuit Service Interface ([I-D.boro-opsawg-teas-attachment-circuit]). I suggest s/must be/can be/ and s/via/via a configuration such as/ Otherwise your “must” makes the two references normative. [srld] ACK. Changed to “is passed” -- 3.4 Is this section assuming that the transport network only supports one 5G provider? That is, in stating that the eMBB slice is global and first, and that subsequent slices share the CP, there is an implicit assumption that there will not be other RANs supported by the same TN, but using other eMBB slices. The text… At the time of writing (2023), Section 6.2 of [NG.113] specifies that the eMBB slice (SST=1 and no SD) should be supported globally. This 5G slice would be the first slice in any 5G deployment. …is, perhaps, a little vague: “at the time of writing”, “should”, “would be”. [srld] Yes. Good point, we will be looking to rephrase it. -- 4. 5G functions can expose the 5G slices to the transport Domain It’s not clear to me why the transport Domain needs to know about the identities of 5G slices. I think it is possible that there is a point in the system that is responsible for aggregation/multiplexing/mapping from 5G slice to transport slice, but it isn’t clear to me that this point is *in* the transport domain. Can you clarify the text to explain what this is all about. [srld] This is described as an option. I.e., no “needs”, but “can”. Even many normative RFCs have some optional features, that can be implemented, but are not mandated. The clarification text is already in the draft (paragraph starting with “One benefit of embedding the S-NSSAI…”). [af] I’ll look again at this to see if you explain why this layer violation might be useful. -- 4.1 However, SDPs for a same slice at different locations may also use different VLAN values. Therefore, a VLAN to IETF Network Slice mapping table MUST be maintained for each AC, and the VLAN allocation MUST be coordinated between TN orchestration and local segment orchestration. I think you can replace “MUST be” with “is” in both cases. [srld] Ack. -- 4.2 Note that this addressing scheme is local to a node; intermediary nodes are not required to associate any additional semantic with IPv6 address. One benefit of embedding the S-NSSAI in the IPv6 address is providing a very easy way of identifying the packet as belonging to given S-NSSAI at any place in the transport domain. This might be used, for example, to selectively enable per S-NSSAI monitoring, or any other per S-NSSAI handling, if required. In the first paragraph you say that intermediary nodes are not required to understand the IP address semantic, while in the second paragraph you give an example of understanding the IP address semantic at transit nodes. [srld] There is no contradiction here. It is not required (not mandated), but might be used (as an option) for additional functionality/visibility. [af] Well, that doesn’t work very well in a specification. In order for this function to work, the “local to a node” scheme needs to be well-known within the network. That won’t work unless there is a way to coordinate the addressing scheme between all nodes that impose it (all edges) and all nodes in the network. That is what a specification would do. Further, if the addressing scheme is local to a node, it would be used at the ingress to the transport network and could help with packets flowing in the opposite direction. But isn’t the knowledge also needed at the egress from the transport network? [srld] Added some explanation, that is local to the ingress/egress NF [af] This requires coordination of the addressing scheme. Since an egress might receive packets from multiple ingresses it needs to coordinate with them all (or the ingresses need to use a standardised approach). How is this achieved? (I’m not a fan of encoding additional semantics into IP addresses. It is, of course, a viable engineering solution – it just feels dirty. Mapping tables are just so much nicer.) [srld] This is IP address allocation scheme. One option is to maintain mapping table, another option is to allocate IP address in such a way, that mapping table is not needed. Both options are possible, and depending on the operator’s requirements, either can be used. In the draft we are not excluding either option. -- 4.3.2 MPLS labels are allocated dynamically, especially in Option 10B Deployments “especially” is a bit weird in this context. If labels are allocated dynamically, then there is no special case. [srld] Ack. Removed especially -- Option 10C in 4.3.3 looks quite interesting. Hope to see some text here. [srld] Yep. We will expand this in some subseqiuent version of the draft. -- 6. This document refers to such tunnel groups as 'transport planes' This might not be the wisest redefinition of the term “transport plane”. https://www.itu.int/ITU-T/studygroups/_COM15/otn/transport.html https://www.slideserve.com/aretha/transport-plane https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20knowlege%20plane%2 <https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20knowlege%20plane%252> 0for%20the%20internet.pdf Anyway, what is the difference between a transport plane, an NRP, and a filtered topology? It would be helpful to put the transport plane in the context of draft-ietf-teas-ietf-network-slices. I know you are architecting with a single NRP, but that leaves you no way to partition any further. Hence, I think, your “collection of tunnels”. Seems broken to me. [srld] This draft focuses on realization with single NRP, and at the moment we have no ambitions or plans to discuss multi-NRP realizations. Realization with multiple NRPs is out of scope of this drafts (there are other drafts discussing multiple NRPs). “Transport Planes” is the term used already in some other WG adopted drafts. E.g. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct. It is just reused here. The “group of tunnels” or “collection of tunnels”, or “tunnel mesh” with similar characteristics (i.e. GOLD, SILVER, BRONZE) tunnels, is the technique commonly used by many SPs since decades, so, it is certainly “existing IP/MPLS technology”, where this draft focuses on.. [af] Not sure you answered my question. You just reiterated that you intend to focus on a single NRP, a point I already acknowledged. -- 7. For its decision-making, the SMO needs information from the NSC about the observed latency between DCs. Preferably, the NSC would present the topology in an abstracted form, consisting of point-to-point abstracted links between pairs of DCs and associated latency and optionally delay variation and link loss values. This is an interesting conjunction of the function offered by ALTO (to determine which end points to connect to) and the IETF network slice service. Not sure it is the NSC’s responsibility to report the network capabilities to the SMO, but *some* component in the transport network needs to do this. An alternative would be a PCE or direct reporting from the network using (say) BGP-LS. [srld] Indeed. We plan to explore it in some future draft version [af] So you will be removing “Preferably”? -- 9. I hope you can find some more words for the security considerations. [srld] Yep. We have updated security section. See draft v-07. ==Nits== [SNIP]
- [Teas] WG adoption poll: draft-srld-teas-5g-slici… Oscar González de Dios
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Krzysztof Szarkowicz
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Julian Lucek
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… John E Drake
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Aihua Guo
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Xufeng Liu
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Jeff Tantsura
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Daniele Ceccarelli
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Richard Roberts
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Adrian Farrel
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Krzysztof Szarkowicz
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Adrian Farrel
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Julian Lucek
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Dongjie (Jimmy)
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Krzysztof Szarkowicz
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Gyan Mishra
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Oscar González de Dios
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Oscar González de Dios
- Re: [Teas] WG adoption poll: draft-srld-teas-5g-s… Oscar González de Dios