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

Uma Chunduri <> Tue, 20 April 2021 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07DBF3A08ED for <>; Mon, 19 Apr 2021 18:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 47--7J04mZT8 for <>; Mon, 19 Apr 2021 18:54:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F0603A0901 for <>; Mon, 19 Apr 2021 18:54:49 -0700 (PDT)
Received: by with SMTP id c195so41120837ybf.9 for <>; Mon, 19 Apr 2021 18:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DS0PmD7Q+IJno5+HL0IuEouQxyVCh4fTWIDs3B8nyzs=; b=u5HcNikD3SwgFOiSlbiDLLEwiuX6JEaMC3aqjQbG+QepkJYfM9nJNwRKHwG89Hew1D euLUXPHCm0nsMxaDNidsicbIbM2dXCB8w+yQHW5JpI/142RJP4XIQ7AjYiFXp4Y5/uDr oHtTa/qr5+54HL1K1QFV7GaEzfe8iCppAMLRWvRL0HZS/jpnqSPHshjNcntUFkeGEubj s7lBNFc+At4xtfunKpcAe8Ehzz8UNjXrAcnL+Se1e4iw4lGe9YvJ1KZZiX1JOrZarBcZ /55hLHjvqSj43ttO+gQcH2DyXJ4iCs8ajrcUAWfAooys2mwKy+kA7db6IjknDT+bj1Ai LSmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DS0PmD7Q+IJno5+HL0IuEouQxyVCh4fTWIDs3B8nyzs=; b=PPaOce25flPWH0GCIOR7V2ot5Ftjv/d9Kg7bvMoMGwWSEpBtv6tBu7gUJT1MzyJN/N 4UEv/jMHuUwfT1qkQyz/MC9IUwFGkrbgNTc4VuVjkxlluotY97FY3LcTV0qRRiz4MMmw oarA5QxDVotxz2QakkhuWCzyrIGEXxUphbLKyegfHnOkm6ZfC9YmuPhhrZYxf2KlQbd3 24pAtcySBgiz1A0ZxVtZRbzRiPDPslri2boK5AY5RmseRa5T6ueyjsRJrBSZ8CFtIxeL 0UFPt7yG+ZdZjqaaJNJIDcn/0dogFTD+py3JVQCsPcEmzbSfT52lp3aUhMdjZbBK2zio TqJg==
X-Gm-Message-State: AOAM532xB3ul2gHnsoOqkUgTOZNKQWWpIpCBqfjIBAggWwwbKQIOylFz Vkw0YNm5TGsRjQEFBmpPMoPFJxb79oNLIXC9voUte9oy9PngEQ==
X-Google-Smtp-Source: ABdhPJwOlVuCvHqTMdnk2CS6wGnXk6Iq//aAaXXquZSolasakjj+NNIbX6+WItB4QYVB+7j2Z962kdTMVNI5QCoOpXE=
X-Received: by 2002:a5b:b4a:: with SMTP id b10mr20998688ybr.182.1618883687644; Mon, 19 Apr 2021 18:54:47 -0700 (PDT)
MIME-Version: 1.0
References: <001001d732ac$c61a6020$524f2060$>
In-Reply-To: <001001d732ac$c61a6020$524f2060$>
From: Uma Chunduri <>
Date: Mon, 19 Apr 2021 18:54:36 -0700
Message-ID: <>
Cc: TEAS WG <>
Content-Type: multipart/alternative; boundary="0000000000002282c505c05dbb09"
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: Tue, 20 Apr 2021 01:54:55 -0000

Hi Adrian and all co-authors,

First of all thanks for the efforts in combining the document.

I have few comments and it would be great if you can take a look at those
in the future updates.


Uma C.

1. Section 1

   This document also provides a framework for discussing IETF Network
   Slices.  This framework is intended as a structure for discussing
   interfaces and technologies.  It is not intended to specify a new set
   of concrete interfaces or technologies. "

   Thanks for defining the scope of the framework document.
   But there is a lot of  work to be done (IMO)  to realize what's been put
in this document and it's good to call out that aspect too.
   For example as specified in Sec "such as guaranteed
   minimum bandwidth, guaranteed maximum latency, maximum permissible
   delay variation, maximum permissible packet loss rate" -
   we simply can't do these in the shared underlays today or can we?

2. Section 1

   The above is reinforced with the last paragraph. How do we define the
"beginning" ?
   Slices topic has been discussed in the design team for almost 1.5 years
and in the IETF for 3+ years.
   So I am not sure, this can be defined and it is helpful.

   Section 1.1:
   This document specifies a framework for the use of existing
   technologies as components to provide an IETF Network Slice service,
   and might also discuss (or reference) modified and potential new
   technologies, as they develop (such as candidate technologies
   described in section 5 of [I-D.ietf-teas-enhanced-vpn])."

   Can we reconcile the above with Section 1 statements?

3.  Section 1

   [I-D.ietf-teas-enhanced-vpn] has been referred throughout the document
 (in sec 1, 3, 5, 5.5, 5.5.1), maybe
   this is because of yet to be streamlined text from both documents. It
appears this is a mandatory for IETF network slicing
   But can this document discuss what ought to be done if there is no
VPN/enhanced VPN?

   *I would note - there are early slicing deployments (in LTE networks)
either with existing VPN
   technologies or *no* VPN technology to realize the slicing (I was
involved in such deployments).
   Please don't misunderstand statement as against
   to enhancedVPN (which nicely documents how better underlay technologies
can be effectively used with VPNs).

4. Section 1
   "The common or base network that
   is used to provide the VPNs is often referred to as an underlay

   Common network doesn't provide VPNs but rather allows multiple VPNs to
share the network.

   "a VPN may in turn serve as an underlay network
   for IETF Network Slices"

   I am missing something here on how? Also this contradicts the earlier
statement. Can you elaborate more here?

4. Section 4.2

      It's good to cover the link between the NSE and the IETF network
node, which is part of the network topology.
      This is generally needed in E2E scenarios and there is a lot of work
done here in different WGs for many years.

On Fri, Apr 16, 2021 at 3:39 AM Adrian Farrel <> wrote:

> Hi,
> 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
> cover:
> - 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
> draft-bestbar-teas-yang-slice-policy
>   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
> compromise
>   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
> them
>   Separately and then come up with new definitions text. This may be a good
> topic
>   For our first telechat on the document.
> ACTION: Chairs: Decide what the rules are for having telechat meetings for
> this document.
> Thanks,
> Adrian
> -----Original Message-----
> From: I-D-Announce <> On Behalf Of
> Sent: 16 April 2021 11:19
> To:
> Cc:
> Subject: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 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
> Abstract:
>    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
>    security.
>    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