Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices Fri, 07 May 2021 02:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18F3F3A0D85 for <>; Thu, 6 May 2021 19:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m0AwV7R8nxWJ for <>; Thu, 6 May 2021 19:40:25 -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 AB9B33A0D87 for <>; Thu, 6 May 2021 19:40:24 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id C24FC75416B5988FC5CD for <>; Fri, 7 May 2021 10:40:21 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 6746FC1CBF8B411B22EC; Fri, 7 May 2021 10:40:21 +0800 (CST)
Received: from ([]) by with SMTP id 1472deTU058110; Fri, 7 May 2021 10:40:01 +0800 (GMT-8) (envelope-from
Received: from mapi (kjyxapp07[null]) by mapi (Zmail) with MAPI id mid17; Fri, 7 May 2021 10:40:01 +0800 (CST)
Date: Fri, 07 May 2021 10:40:01 +0800
X-Zmail-TransId: 2b096094a881a156e254
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <037401d740c5$70a9cc30$51fd6490$>
References: 037401d740c5$70a9cc30$51fd6490$
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 1472deTU058110
Archived-At: <>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
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, 07 May 2021 02:40:31 -0000

hi Adrian,

Some typo or comments for your consideration,

Page 10, the first line: be determined [by] the customer...

Page 12, in 4.2:  the 'multipoint-to-point' is duplicate.      

                The IETF NSE[s] are conceptual points of connection ...

Page 12,  it says,

'An NSE should be identified by a unique ID in the context of an  IETF Network Slice customer.'

'A combination of NSE unique ID and NSE attributes defines an NSE in the context of the IETF Network Slice Controller (NSC).'

The unique ID of NSE is in the context (or name space) of IETF Network Slice customer. The context/name space of IETF Network slice customer may be different from the context of IETF network slice controller, considering, for example, difference customers could use different the same unique ID in their own customer contexts. It may need to consider the difference between the customer context and NSC context in order to keep the ID unique.

Page 20, 'IEFT' typo

Page 20,  'are mapped to the underlay IETF Network Slice Endpoints   (NEPs)'.    The abbreviation could be NSEs while not NEPs.

Page 24, security consideration, ' as some aspects of security may be expressed in SLOs.'    

    According to, security is expressed in SLE, and here, the SLOs could be SLEs.


Xiaobing NIU


日 期 :2021年05月04日 17:11
主 题 :[Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Several important points:
1. This is work in progress and you are all allowed to comment on any of the
text. Changes made here are based on text floated on the list and comments
received, but this is NOT confirmed consensus and is still open for
2. You can see the changes this time around at
   a. Eric has retired, but is still following the work
   b. No longer need the Editor's Note in Section 1
   c. "Consumer" vs "customer". I have made this consistent (we only need to
use one
        term). I selected "Customer" because that seemed best, but I know
some people
        prefer "consumer". Please discuss if you are not happy.
   d. Changes for Isolation text and introduction of "SLE" for
"unquantifiable objectives" 
        as proposed on the list, with edits for the comments received
   e. Changes for realisation of network slices as proposed on list, with
edits for the
       comments received.
   f. Various small editorials
   g. Fix ordering of end-matter sections
   h. Remove "Unused Material" Appendix (as it was unused :-)
3. Next work topics (in no particular order)
   a. Definition of a Network Slice Service (based on a discussion started
on the list by John Drake)
   b. Definition of End Points (ditto)
   c. Resolve "duplication" between Figure 1 and Figure 3 as well as
surrounding text
   d. Propose a functional architecture for realising network slices
4. I think that at least 3d will need a meeting. If 3a or 3b gets a
significant level of
    discussion on the list then it should also have a meeting. I will try to
give a week's
    notice for any meeting and pick a time that works for California and
Beijing. But,
    please note that you don't have to come to a meeting to have an opinion
- that is
    what the mailing list is for.
-----Original Message-----
From: Teas <> On Behalf Of
Sent: 04 May 2021 09:56
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-02.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-02.txt
    Pages           : 32
    Date            : 2021-05-04
   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:
Teas mailing list
Teas mailing list