Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Adrian Farrel <> Sat, 29 August 2020 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B5D63A1018; Sat, 29 Aug 2020 14:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qq7ne5VPmFY8; Sat, 29 Aug 2020 14:06:45 -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 963EA3A0B98; Sat, 29 Aug 2020 14:06:43 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 07TL6f21016555; Sat, 29 Aug 2020 22:06:41 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 63E0622044; Sat, 29 Aug 2020 22:06:41 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 4D96522042; Sat, 29 Aug 2020 22:06:41 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 07TL6ehd025536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Aug 2020 22:06:40 +0100
From: Adrian Farrel <>
To: 'Lou Berger' <>,
Cc: 'TEAS WG Chairs' <>
References: <05b401d67d8a$4ddf5890$e99e09b0$> <>
In-Reply-To: <>
Date: Sat, 29 Aug 2020 22:06:40 +0100
Organization: Old Dog Consulting
Message-ID: <007101d67e48$4a8edcb0$dfac9610$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH8yyqMLj2FV5vO4hw7YvnJLKd3IgFWxy9RqPg5/IA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--11.663-10.0-31-10
X-imss-scan-details: No--11.663-10.0-31-10
X-TMASE-Result: 10--11.663400-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbLqImyaR0axZMVx/3ZYby78G2HMvWEJentUw yrj5Civyuy5L9zYU1E0B5VDY2TkRRXqE/IIafU+/qjZ865FPtpoO9z+P2gwiBQJxDD/ayJRm6Za mopeZkvkUJdZ1HmvkUv0q3tG0LXi9DgAHIS2EadEZ9MKxHrUy4fIK8gK4rjpyWtcoU8Jtc7lj6y 1eE6mExfF2O74R6MgK5tsmnCSluamNZN06X0JyVTVNQerZ0cSEAgvM6h73Btp4e/u6WfZmUdO/Y 9RMDWyU9Csf7hhk5u+4J8EOeEZLm7UTfo0SbsRoi+quUbDYb+SDy9ksrAYVGOJ4ZAtEhpMklw+f 7XtsUQ9QGtlgt2g3mOORc+mJA7zJtI2CEEMRxDED2WXLXdz+AX23AkKVZZKXQJWgm/s1UB8DE6k /i6Y0RfsupqkTxD9s7POegsjHfkfVDncypCNbyPIq3+8DQd0oQWEGv3gaUmfuLrWPHZAw8iVIq/ lxS7KcKizFq/tv3XNOMEQFWdYpZPSQtYfOFz1BIAjxomarSPDYt7feNOis5oHXLqlE2qxyxytww T/CqKeODh9/UBkMhHh4x4OeN4pRrezMgYy7e85uXgIqq6mQyvMMVfCUdzao5Wx90MBPE1L3h2jy bQkTkjbvUfEvkpCDtuPb5PBt9q2Mcenel/LSetWvZ0LprH5qBGwExtNOAA8XY+gNTubOQHn9Hfu iScGp0GKpxI6So2lrsJa56rx8YgHrvE+oAkbolVHM/F6YkvT8vWy4J4eAKeTWTJAOkSPwKPndoQ HmoMubWIefkzyak5fvqX7qGxPjv7Q5vATVUMueAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5d3 cxkNQwWxr7XDKH8eORG6jGgooO7jHLMkiwPB1htDDFSg3PeRbZyjeRu8JaIe1RnELbIqg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing
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: Sat, 29 Aug 2020 21:06:47 -0000

Hi Lou,

Just to be clear, text was not removed from draft-ietf-enhanced-vpn and moved to draft-king-teas-applicability-actn-slicing.

draft-king-teas-applicability-actn-slicing pre-dates the enhanced VPN work and only lapsed when the enhanced VPN draft was brought to TEAS from RTGWG, and some (a lot?) of the same material was brought into the enhanced VPN draft.

But I think you bring out three good points for discussion:

1. Is enhanced VPN sufficiently equivalent to network slicing to mean that discussing "realisation of VPN+ using ACTN" is a duplication of discussing "applicability of ACTN to network slicing"? My opinion is that when viewed at the service level, VPN+ and network slicing are very, very similar. However, despite having the enhanced VPN framework that described network slicing, the working group decided it wanted a network slicing design team. That team has not come back with a statement that the two concepts are very similar and has, in fact, produced its own framework for slicing that might (or might not) overlap with a current working group draft.

2. Should draft-ietf-teas-enhanced-VPN go in to details on technologies that can deliver VPN+ or should it focus on describing the function and architecture that is an enhanced VPN? The current section 5 ("Candidate Technologies") gives a very brief description of the different network and management technologies that could be used, and highlights areas for future work, but it does not dig deep into solutions. Indeed, there are a number of related solutions drafts in other working groups (LSR, BESS, SPRING,...) that set out more detailed solutions work. In that respect, the old sections 5.6.1 and 5.6.2 were overly detailed compared to the rest of section 5, and removing text seems to have been a reasonable thing to do.
3. How many is too many Informational documents? While the various VPN+ solutions drafts in other WGs are marked as Standards Track, it is a strangeness of where we are with ACTN that there is already and architecture and there are already YANG models (done or being worked on) that address all of the protocol needs. All that a document requires to do is show which of those models to use where and when in order to enable support for network slicing using ACTN, and that makes the document Informational. Once upon a time it was quite popular to write "cookbook" style Informational RFCs that helped people work out how to pull together bits of technology and build systems.

Depending on the discussion of these three questions we could:
a. Pull material from draft-king-teas-applicability-actn-slicing into draft-ietf-teas-enhanced-vpn and abandon draft-king-teas-applicability-actn-slicing
b. Adopt draft-king-teas-applicability-actn-slicing and publish both it and draft-ietf-teas-enhanced-vpn
c. Abandon the work of the network slicing design team folding new text into draft-ietf-teas-enhanced-vpn
d. Adopt and publish lots of documents
e. Any combination of the above

I think it is reasonable to ask the WG:
- Is there a substantive difference between VPN+ and network slicing?
- Do we want to describe how to use ACTN for network slicing?

I don't think it is reasonable to ask the WG:
- What documents do you want to publish to achieve all of this?
This is my belief because the WG is focused on technology not the niceties of publication. Actually, you either have to take the documents that people are working on, or you (as chairs) have to tell us what documents we should be working on (to which me might, of course, object :-)

Lots of fun?


-----Original Message-----
From: Lou Berger <> 
Sent: 29 August 2020 19:56
Cc: 'TEAS WG Chairs' <>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Hi Adrian,

On 8/28/2020 6:26 PM, Adrian Farrel wrote:
> ...
> Looking forward to your thoughts on this.

     As we (chairs) mentioned to you off-list, before we can talk about 
adoption of this document we still have the issue of working through the 
discussion at the last meeting.  Specifically the text that was removed 
from the WG document ( draft-ietf-teas-enhanced-vpn) that is largely 
present in this document.  My question is: assuming the text in is 
restored from draft-ietf-teas-enhanced-vpn-05, are there one or more 
suitable existing (or candidate) WG documents that could be a home for 
the remaining valuable text that is currently in 
applicability-actn-slicing document? -- after all how many information 
documents do we really need on this topic....

I think this is a question not only for you and your coauthors, but also 
for the WG as a whole.



> Best,
> Adrian
> _______________________________________________
> Teas mailing list