Re: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt

Adrian Farrel <> Fri, 16 April 2021 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98E963A3161 for <>; Fri, 16 Apr 2021 12:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.782
X-Spam-Status: No, score=0.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=2.699, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PcvoeUjfVwEO for <>; Fri, 16 Apr 2021 12:06:19 -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 EC3053A315F for <>; Fri, 16 Apr 2021 12:06:18 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 13GJ6D3t006005; Fri, 16 Apr 2021 20:06:13 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 636FA2203C; Fri, 16 Apr 2021 20:06:13 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 4E5082203A; Fri, 16 Apr 2021 20:06:13 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 13GJ6C6a004862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Apr 2021 20:06:12 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Daniele Ceccarelli'" <>, <>
References: <001001d732ac$c61a6020$524f2060$> <>
In-Reply-To: <>
Date: Fri, 16 Apr 2021 20:06:12 +0100
Organization: Old Dog Consulting
Message-ID: <007201d732f3$9191eb60$b4b5c220$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGrcLj93g4hIPb6J7wv6awwtLf4dAJIUC/Yqvy/ORA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.572-10.0-31-10
X-imss-scan-details: No--13.572-10.0-31-10
X-TMASE-Result: 10--13.571900-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGyoI+bK8UPQmmpWpGzPzJd6uVri61Nit+qvcIF1TcLYBPk 4TRKPbLh8ImBF4op0ZoCQieGFUjcURNmUW1dq3NxUNaPigviKR+lAfiiC1VA/bcDOENjmIpLjiZ qRZIhdsMC2RTaQnp3b9zNGy0Mjrmt0gr3NjadPd8Fxov+3JYvY25MoGKfGX+6n7jOJQ+rgvFe5z eXRLbZF3lvmAHfNM/O3un1d696gAA/S0lB86bnABlJRfzNw8afY/8hgefJn7D7eDzreGwykapTO 1SqMj842e3gT7Q14/uzdO/WFBq0Q7NFdXOVxOU0awF+mgcxqmUZskwWqoib3FgLks93sG9t2Cis uPjstxQfd1ekiGv/EKpcWZZj8/uLP0DBdQeKlX30VCHd+VQiHg9Mm+1DE1vOIV8tFcvAktQ2eL1 /gwRNt0bF98KsPyw4qvum1jVL8l9pvFfO7807PmlO3nte6oxzT5ysQDj6eFmH9gaGATvJBTQOm2 OwY/H7dZ7fu9NDAa5oxXoWL2GVj7fUXJkZwSh1o1Ph4mwugyvqCtbLr8G6vmu9/l5WAy7s7LVRS /+15GiKfLaZj2ve7SxiLRl0B2nO36eSajIECZnqgypI9NhGdSFceJVsZ+5jMa/5v/+qErZ4erum 6JkyFXHCBTASzvaREnbMkUwDMHsOxywZvxxGJP7FEhWgo0y8SExQHIFQcSuHuEJP9TlHY+4twbG t+qcKFYCNH0u3h8WWGxqQB/iCI1JVOThx4Ffx3zen1b+Th8qRgLeuORRdEjq204RF2dLYWmrYr8 SaWTXADkk7xXC/bY+UfGekgkQDewUovYn5XK2eAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtBvSi/Fk2cquKfdXgBPsxhsZVDCCMM249UiwyUS2H03+v32nLdf6ezg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-slices-01.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: Fri, 16 Apr 2021 19:06:24 -0000

Hi Daniele,

> Regarding the discussion on realization.
> Maybe we could have section 6 split into an analysis of existing tools,
something like:
> 6.  Applicability of existing IETF tools to IETF Network Slices
> 6.1 ACTN
> 6.2 Enhanced VPN
> 6.3 draft-bestbar

Yes, that's the split I am seeing (although may need a better name for 6.3).

However, I don't envision much text in each section. IMHO, this document is
not the place to expound in detail on the realisation possibilities. Once we
have established the key architectural points in this document, people can
write other documents (applicability statements) to explain how their
favourite approach can be applied to satisfy the architecture.

> (I still believe the VTN can be a particular type of VN...but this is
another story)

That is a discussion that is really worth continuing, but I think it is
outside the scope of this document.

> Willing to be more creative we could split them into data plane, and
> plane?

I wonder whether this should find its way into...
     5.5.  Realizing IETF Network Slice  . . . . . . . . . . . . . .  20
       5.5.1.  Underlying Technology . . . . . . . . . . . . . . . .  20


-----Original Message-----
From: Teas <> On Behalf Of Adrian Farrel
Sent: den 16 april 2021 12:39
Subject: [Teas] New Slicing revision: I-D Action:


In this revision, I have tidied the text. That involved:
- Fixing inconsistent editorial standards between the source documents
- Some more minor editorials
- Moving a couple of sections around
- Collapsing a little duplication arising from pulling text from two places
- Removing cross-references between the source documents
- Removing the tagging of the source material

In doing so, there were two small paragraphs that didn't seem to belong.
These can be seen in the Appendix.

ACTION: All: Please shout if you believe this text should not be deleted.

While this document is now in a condition that can be reviewed and commented
on, I propose to make some suggestions to reduce and consolidate the text. I
will bring these to the list as separate threads (some have already been
seen on the list, but we should make the proposed changes clear). They will

- Discussion of realisation.
  This should be a discussion of architectural realisation, not of
underlying technologies.
  Currently we have:
   - a large section on ACTN
   - a couple of references to VPN+
   - no mention of the architecture underlying
  I already suggested (on list) a way to reduce the ACTN text, but it has
since been
  proposed to me that all discussion of realisation of the architecture can
be best
  achieved with brief paragraphs and references. I will propose text.

- Isolation and "unmeasurable SLOs"
  This has long been a contentious topic. I think we had reached a bit of a
  in the definitions draft, but doing the merge has caused me to re-read it
and I am
  uneasy. I will be making a text suggestion to clarify the purpose and
meaning of the
  section on isolation, and that will depend on us also clarifying the
description of
  "directly measurable SLOs" and "indirectly measurable SLOs. 

- Revisiting the definition of a network slice
  This is obviously pretty core to our work! John Drake previously sent a
suggestion to
  the list (2021-04-03). This caused a bit of discussion and raises a number
of points.
  I plan to try to tease out the various points to see whether we can agree
  Separately and then come up with new definitions text. This may be a good
  For our first telechat on the document.
ACTION: Chairs: Decide what the rules are for having telechat meetings for
this document.


-----Original Message-----
From: I-D-Announce <> On Behalf Of
Sent: 16 April 2021 11:19
Subject: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
This draft is a work item of the Traffic Engineering Architecture and
Signaling WG of the IETF.

        Title           : Framework for IETF Network Slices
        Authors         : Adrian Farrel
                          Eric Gray
                          John Drake
                          Reza Rokui
                          Shunsuke Homma
                          Kiran Makhijani
                          Luis M. Contreras
                          Jeff Tantsura
	Filename        : draft-ietf-teas-ietf-network-slices-01.txt
	Pages           : 33
	Date            : 2021-04-16

   This document describes network slicing in the context of networks
   built from IETF technologies.  It defines the term "IETF Network
   Slice" and establishes the general principles of network slicing in
   the IETF context.

   The document discusses the general framework for requesting and
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and how
   abstract requests can be mapped to more specific technologies.  The
   document also discusses related considerations with monitoring and

   This document also provides definitions of related terms to enable
   consistent usage in other IETF documents that describe or use aspects
   of IETF Network Slices.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

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

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list
Internet-Draft directories: or

Teas mailing list