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]