Re: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

Adrian Farrel <> Mon, 20 July 2020 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D76F3A0D25 for <>; Mon, 20 Jul 2020 09:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y1Q_vGr_tXVw for <>; Mon, 20 Jul 2020 09:44:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3C5A3A0BF1 for <>; Mon, 20 Jul 2020 09:44:14 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 06KGi9GO018963; Mon, 20 Jul 2020 17:44:09 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id AA98F2203D; Mon, 20 Jul 2020 17:44:09 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 955C32203C; Mon, 20 Jul 2020 17:44:09 +0100 (BST)
Received: from LAPTOPK7AS653V ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 06KGi8iw013759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jul 2020 17:44:09 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Daniele Ceccarelli'" <>, <>, <>
References: <> <000001d659b5$f021d4f0$d0657ed0$> <>
In-Reply-To: <>
Date: Mon, 20 Jul 2020 17:44:08 +0100
Organization: Old Dog Consulting
Message-ID: <00da01d65eb4$fd7696a0$f863c3e0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01D65EBD.5F3D6FA0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJxGDC4suh2J78pwwWz9frRtQUvKQD6n3ICAZzCpJSnxjeFsA==
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--29.130-10.0-31-10
X-imss-scan-details: No--29.130-10.0-31-10
X-TMASE-Result: 10--29.129900-10.000000
X-TMASE-MatchedRID: CxmI61mtwh9or4mPA3EMtnFPUrVDm6jtcVr+FAe3UDVPvOpmjDN2ki8G 2Ltt4jDGqthi32DRSIIFfbBuBeRh859vFrcDXJOnVUIE0/jxA/1uwUsg2ZgJ8beW2B07O0Pw7vw kzz88kq37iC9f0tqljjRVVCZFKVr2mrcavHa2c/6QgeuUY0WN7MQG7ZKPvq1p31GU/N5W5BBH58 uds0vZkhMg6dnBATaeZCnkPZwH07rJaZymIE2ju2gws6g0ewz2j0jXY9STMgELt1T6w2Ze0u4FL YiGdXwWFsyzXCRuvT+6xmKX9u080L5Fo8Eg21LkalRqQPhHMT5Lew0dUDGibCR8AwLDToB4t/58 gDWuL9iXuU9fbuZfRyy+GQnwDGCz7ZpdgJkP1WJn48JV2n32HyNQ2802DkHxGUs9b7xvtJpX68t VEVIE0JXl0jnm1bqLLrXbjHT3QiPD6qR0cYb6viHAISRvClxYDmTV5r5yWnpGM2uNXRqsUnYiGl qls41yixtyeq8HXD0oPCbFUtFI0kNGymtYrC0P9Ib/6w+1lWTM8zLNncnslVm3w6Cmg+wN60lvT PmgaWpJFBlf1Td1afwMx3EaIrwBpvrSLvF7r4ctep5gtv80qljWwaUPviNZKsMDWBh/KG8Hb6Rj bcRCabSMRgd+uNfExtgTkG+GaOfecSkNT7l/2ThiciQR/+DQo9NrOX1+l63coLmjH3CUeCzrMMF 3CEtH3F+J5tvxEjcwn9g3uUMn00nHN0zFWgL2w+OcqR96DFeQBbTqDF++CjhYIK0miWBFG0ZV9a 36VW+aWwy/72Hp+wrv8j9IgKVjcfRJq1ctTfyeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyJGNS8BP La+j6ebHCxzBV4TKzfM9B6IRt5FGCd0S0NCshoCgwc7gvNSReh7JitKf0edmRkHJxbDNzu+Qc66 sHZgYDttQUGqHZU=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2020 16:44:19 -0000

Hi Daniele,


Adding my thoughts because, well, that’s what I do, sometimes.


It’s good to be talking about this slicing work on the WG list.


> Just a couple of comments from my side:


> Applicability ACTN to TE Network Slicing: does this imply that it is

> possible to do slicing also without TE?


I believe it is possible to slice a network without having TE. Some rudimentary examples exist in DSCP or in the way routers can be configured to partition the buffers/bandwidth for best-effort and TE traffic.


ACTN (of course?) is a TE technology and applies to TE networks. So this draft would apply to slicing of TE networks.


Probably (?) the TEAS working group develops TE technologies.


> "...indicates where ACTN might be extended." - Probably it's worth changing

> the scope of the draft. It's not just applicability but something more, something

> like applicability and gap filling?


Good question. It is possible that the authors intend to identify the gaps, write protocol documents to fill the gaps, and then convert the gap analysis into applicability statement. IOW, by the time the document becomes and RFC (that’s one for your grandchildren) there will be no gaps and it will be a ‘pure’ applicability statement.


> Terminology section: “The terms defined below are intended to give context

> and meaning for use in this document only and do not force wider applicability”.

> Maybe we can use terms within the scope of the document till we will have

> standard terms to replace them with. (draft-nsdt-teas-transport-slice-definition

> -03 could be the source). Others seems to be quite generic and not depending

> on network slicing. 


Right. At such time that the WG reaches consensus on slicing terminology, it would be wise for all WG documents and prospective WG documents to adopt the same terminology.


I think that what this document is saying is that it is using terminology for the sake of making it possible to understand the document. It looks to me that the authors are not trying to enter into the debate that the network slicing design team is likely having, although I’m willing to believe that the authors would be delighted if the DT adopted the terminology from this draft 😊


> Transport network slice: Brave usage of the word “transport” 😊


I can’t help agreeing! Although I like the way the fact of “transporting another service” is made clear. Thus, it is the use to which the slice is put that makes it a transport slice: it is not a question of the technology used to provide the slice.


> Section 2: requirements for network slicing – I would suggest to focus 

> on “requirements for transport network slicing” instead. Moreover this

> is yet another topic which is covered from the NS DT. Probably this

> section would fit better into “draft-nsdt-teas-ns-framework-02” ? 


Here I would disagree strongly. The document is about network slicing more generally (the definition is there just above the definition of transport network slice). Why should the WG limit itself to this restricted concept? The text is quite clear that the scope is limited to IETF technologies.


As to whether this text is picked up by other drafts, that’s an open question. 


> Section 3.2.4 – This is probably the most interesting part. What the service

> provider usually sells to a customer is a VPN and the service mapping

> functionality is used to bind a VPN to the TE infrastructure and hence meet

> the SLA/SLO requested.


I agree. See the VPN+ work.


> In the latest version of the TE service mapping draft we added the support

> for network models (L3NM and L2NM) in addition to the Service Models.

> This is to allow the operator to specify a binding request in the ACTN

> framework and not just the customer. The section might need to be

> updated to the latest version of the mapping draft (v04)


Yes, that is so.

And I think that there is more work coming from several people on “network slice as a service” which also might be categorized as an NBI for network slicing.

We should consider that the “customer” for a slice may be an internal organization of the service provider.




-----Original Message-----
From: Teas < <> > On Behalf Of <> 
Sent: den 14 juli 2020 10:08
To: <> 
Subject: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt


Greetings TEAS,


For your reading pleasure we recently updated our ACTN applicability to network slicing I-D. 


Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing  <>


The tldr version, we updated the document to point to a candidate YANG model for transport network slicing (draft-wd-teas-transport-slice-yang). We also fixed some NITs and identified some additional/future work. 


As always we would love to hear from the WG participants. Did you find the I-D useful, not so useful, are we on the right track, what is missing? All feedback acknowledged and gratefully received. 


See you (virtually) soon. 


BR, Dan.


-----Original Message-----

From:  <> < <>>

Sent: 13 July 2020 20:47

To: Haomian Zheng < <>>gt;; John Drake < <>>gt;; Daniel King < <>>

Subject: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt



A new version of I-D, draft-king-teas-applicability-actn-slicing-06.txt

has been successfully submitted by Daniel King and posted to the IETF repository.


Name:                                        draft-king-teas-applicability-actn-slicing

Revision:          06

Title:                                           Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing

Document date:                       2020-07-13

Group:                                       Individual Submission

Pages:                                         17

URL:             <>

Status:          <>

Htmlized:        <>

Htmlized:        <>

Diff:            <>



   Network abstraction is a technique that can be applied to a network

   domain that utilizes a set of policies to select network resources

   and obtain a view of potential connectivity across the network.


   Network slicing is an approach to network operations that builds on

   the concept of network abstraction to provide programmability,

   flexibility, and modularity.  It may use techniques such as Software

   Defined Networking (SDN) and Network Function Virtualization (NFV) to

   create multiple logical or virtual networks, each tailored for a set

   of services share the same set of requirements.


   Abstraction and Control of Traffic Engineered Networks (ACTN) is

   described in RFC 8453.  It defines an SDN-based architecture that

   relies on the concept of network and service abstraction to detach

   network and service control from the underlying data plane.


   This document outlines the applicability of ACTN to transport network

   slicing in a Traffic Engineering (TE) network that utilizes IETF

   technology.  It also identifies the features of network slicing not

   currently within the scope of ACTN, and indicates where ACTN might be






Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at


The IETF Secretariat





Teas mailing list