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

Adrian Farrel <adrian@olddog.co.uk> Wed, 21 April 2021 17:10 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4813A2FCC for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 10:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.784
X-Spam-Level:
X-Spam-Status: No, score=0.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=2.7, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BshHQqI2TIWw for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 10:10:01 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244CF3A2FC8 for <teas@ietf.org>; Wed, 21 Apr 2021 10:10:00 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13LH9vj7032158; Wed, 21 Apr 2021 18:09:57 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6FC522204A; Wed, 21 Apr 2021 18:09:57 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 5A1E622048; Wed, 21 Apr 2021 18:09:57 +0100 (BST)
Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13LH9uul019113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 18:09:56 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Uma Chunduri'" <umac.ietf@gmail.com>
Cc: "'TEAS WG'" <teas@ietf.org>
References: <001001d732ac$c61a6020$524f2060$@olddog.co.uk> <CAF18ct6=uX6AdKVbvgW1KRT7kfgME6AecYKS43aStx_H3wtsBQ@mail.gmail.com>
In-Reply-To: <CAF18ct6=uX6AdKVbvgW1KRT7kfgME6AecYKS43aStx_H3wtsBQ@mail.gmail.com>
Date: Wed, 21 Apr 2021 18:09:55 +0100
Organization: Old Dog Consulting
Message-ID: <058701d736d1$276e6510$764b2f30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0588_01D736D9.89347AC0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGrcLj93g4hIPb6J7wv6awwtLf4dAI0zenIqwUISlA=
Content-Language: en-gb
X-Originating-IP: 81.174.197.74
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26106.001
X-TM-AS-Result: No--17.387-10.0-31-10
X-imss-scan-details: No--17.387-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26106.001
X-TMASE-Result: 10--17.386700-10.000000
X-TMASE-MatchedRID: HQYVVRq48Rw7iuZ/mdYYthhFHaqt/HCNEbttIfu93HKSWMy98QXhABo3 /S/YPg4h7DyutiOL/vjx5KZMlKYS/eDTYjejIZTwfyjNXlbBvnTyJm1r5kWPr/GE0aJ8AnbME2Z AXhRGbX0psn9kdROMaeXYI0z4MDj0eF6MevMVZUD+82zEszKLqu87m+Okgjhuvs75gcY5ey6+zI 5xqtGWwokJXr+VAiTlwY28o+cGA5pGI9Mwxz8yaYX+ysHLZnw7xVtHfmq5HMjDiDWMDQWXl1B0f q3CJGfXyIu3I7SYf6iK5Jq39CIIv4hQfPD8Hiq1vStYzicikmuSVHtPeCEUC3uUPCjcAPFZq9oI BwR0YWWXDSrHX5e4HZr5ykm9NtIcQZpQRfyCdHwjlnxOIeMfMPLTFm7Vc1pI28G4m+3NScifhns R7pdgg3imQCA94R1WHWRJEfGP5nmKGt5fJs6lYLKeTtOdjMy6vsXUK28yG1704DNGDcXacq7Udw +xuQKKw6JdELnqjHe+WiZHBuMmvo/O/yyvtrKj4hBGrZ2V5uBLCMYt+C2yUmDStRrSEPbOv7m7z xL1SsMlJvFD4ejYno9Ha73XaFhEHT/HpHydkxJojAWuSDNe9uTsRvdKfAuC0Ez4c9z4hKx/EGw+ HXd8Ww6A5nr1v8T6HcQQBuf4ZFsCC8zqHvcG2ncFOXhOQltmhm6h8PqvGs7PRqKrzwfm1z8F2zk q7L0C1fU93/NXnnlJQAV6arsHZeimxgRHwEwmP4H+2nyK0FO2+61dgKbe0UXotxiaXX/x+bg+kM Dal2t48YB5KfXbgmUjS8bIKMq/YFTPdN5lYYpHQgtCTJ1arKPFjJEFr+ol6AvlZUR4TsgBi3kqJ OK62T/cZn50ezHqi2QFaYS1v23HUU+U0ACZwMkOJ8YxhWbMvsfb7jGZUN4yBHHtSQ6815nL3J3Y ajc3Jlsqxvuy4P5TIt93ZrnfD1Zkna2oJU6A8SfqfWasUmNBKtyDv3maWg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/qN5AYPIBcXyN4tMX3JGcqwIQbdA>
Subject: Re: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 17:10:06 -0000

Hi Uma,

 

Thanks for looking at the text.

 

> 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. 

 

First, this is not my text. This is text taken form one of the contributing documents.

 

> 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 4.1.1.1 "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?



The question of how to realise network slices, in particular how to use existing IETF technologies to meet the SLOs described in this document, is important. But it is a big topic with many possible technical answers. In my opinion, that issue should be addressed in (probably several) other documents depending on the underlying technology, it’s inherent capabilities, and the extensions that need to be developed. For some underlying technologies this may be handled by an “applicability statement” (for example, in the case of the applicability of ACTN when the underlay network is TE-capable) or by protocol extension documents (as suggested by a number drafts – VPN+ and bestbar).

 

But this is just my opinion. If there is consensus that this document should contain a detailed explanation of how to match the objectives of network slicing with the underlay technologies, then we should address that.


> 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.



I agree that that paragraph is not terribly helpful. That said, this is text that the design team produced!

 

I would propose

OLD

   Note that it is conceivable that extensions to these IETF

   technologies are needed in order to fully support all the ideas that

   can be implemented with slices, but at least in the beginning there

   is no plan for the creation of new protocols or interfaces.

NEW

   Note that it is conceivable that extensions to these IETF

   technologies are needed in order to fully support all the ideas that

   can be implemented with slices.  Evaluation of existing technologies,

   proposed extensions to existing protocols and interfaces, or the

   creation of new protocols or interfaces is outside the scope of this

   document.

END

 

>   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? 



Yes, we should. Probably…

 

NEW

   This document specifies definitions and a framework for the
  provision of an IETF Network Slice service.  Section 5.5 briefly

   indicates some candidate technologies for realizing IETF   

   Network Slices.

END

 

Note: My proposal for merging section 5.5 and section 6 (per the thread with Daniele) will follow shortly.

 

> 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

That is exactly the reason. The text is simply merged with some basic edits.

I believe that (per the note above, and the thread with Daniele) this can be streamlined to show that VPN+ is one way to deliver IETF Network Slices in a specific environment.

>   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). 

I believe you might find it valuable to write up a draft describing your deployments.

It may be, however, that you misunderstand the VPN+ work. We saw a similar mismatch of language while doing the L3SM work. A “VPN” is often considered in terms of the protocols and tools necessary to operate a network in order to achieve a particular type of service. For example, we talk about BGP/MPLS VPNs. This is natural as we are engineers many of whom spend a lot of time working with protocols or deploying devices. But there is also a meaning of “VPN” which may be paraphrased as a “VPN service.” That is the consumer’s view of the VPN. When looked at in this way, the enhanced VPN of draft-ietf-teas-enhanced-vpn is not dissimilar to an IETF Network Slice.

> 4. Section 1
>   "The common or base network that
>   is used to provide the VPNs is often referred to as an underlay
>   network,.."
>
>   Common network doesn't provide VPNs but rather allows multiple VPNs to share the network. 
>   s/provide/serve

I don’t understand the distinction you are trying to make.
I suppose that other available words are “enable,” “support,” “build,” and “deliver”.
Does any of these work for you?

> "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?

Networks can be stacked, right? An overlay network may be treated as a fully-fledged network (such is virtualization) and so be an underlay for the provision of another service.
Maybe this should say…

OLD
   As an example technology, a VPN may in turn serve as an underlay
   network for IETF Network Slices. 
NEW
  An overlay network may, in turn, serve as an underlay network to 
   support another overlay network. 
END

> 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.

Good comment, but are you proposing anything in particular?
  
Thanks, 
Adrian

 

On Fri, Apr 16, 2021 at 3:39 AM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > 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 <i-d-announce-bounces@ietf.org <mailto:i-d-announce-bounces@ietf.org> > On Behalf Of
internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> 
Sent: 16 April 2021 11:19
To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> 
Cc: teas@ietf.org <mailto:teas@ietf.org> 
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:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-ietf-network-slices-01
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org> 
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas