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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Apr 2021 11:39:26 +0100

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 <[email-masked]> On Behalf Of
[email-masked]
Sent: 16 April 2021 11:19
To: [email-masked]
Cc: [email-masked]
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.

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

_______________________________________________
I-D-Announce mailing list
[email-masked]
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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 16 Apr 2021 14:11:10 +0000

Hi Adrian,

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

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

Willing to be more creative we could split them into data plane, and control/management plane?

BR
Daniele  

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: den 16 april 2021 12:39
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt

Hi,

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 <[email-masked]> On Behalf Of [email-masked]
Sent: 16 April 2021 11:19
To: [email-masked]
Cc: [email-masked]
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.

Abstract:

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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Apr 2021 20:06:12 +0100

Hi Daniele,

> 6.  Applicability of existing IETF tools to IETF Network Slices

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
control/management
> plane?

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

Cheers,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: den 16 april 2021 12:39
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] New Slicing revision: I-D Action:
draft-ietf-teas-ietf-network-slices-01.txt

Hi,

  

Thanks,
Adrian

-----Original Message-----

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 19 Apr 2021 09:14:09 +0000

Hi Adrian,

Completely agree. 
Please see in line for some more comments.

BR
Daniele  

> From: Adrian Farrel <[email-masked]>
> Sent: den 16 april 2021 21:06
> To: Daniele Ceccarelli <[email-masked]>; [email-masked]
> Subject: RE: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-
> slices-01.txt
> 
> Hi Daniele,
> 
> > Maybe we could have section 6 split into an analysis of existing
> > tools,
> something like:
> >

[DC] yes definitely. Maybe something like: "Network slicing and slice aggregates in IP/MPLS networks"

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

[DC] Makes sense. It's not the scope of the framework to define solutions. An hook to existing work is more than enough. Maybe solution drafts might go into a more detailed analysis of how each solution can meet the requirements.

> That is a discussion that is really worth continuing, but I think it is outside the
> scope of this document.
> 
[DC]  yes, that's a valuable option. Even if as you said above it would be just an reference.

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

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Apr 2021 18:54:36 -0700

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.

Rgrds!

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

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
   network,.."

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Apr 2021 18:09:55 +0100

Hi Uma,

Thanks for looking at the text.

> 1. Section 1
>
> "This document also provides a framework for discussing IETF Network

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

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

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

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.

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

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

>   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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Thanks,
Adrian

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

Abstract:

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

[email-masked] <mailto:[email-masked]> 

_______________________________________________
Teas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/teas

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 21 Apr 2021 20:42:25 -0700

Hi Adrian,

First, many thx for your thoughtful and detailed response. See my quick
comments below ..

Cheers!
--
Uma C.

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

[Uma]: Ack and appreciate your time, and efforts for making this better.

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

[Uma]: Agree and the 'or' above should have been 'and'

> by protocol extension documents (as suggested by a number drafts – VPN+
> and bestbar).
>

[Uma]: Agree. While this is not the thread to comment technically on VPN+
or bestbar, I am afraid these two may not be encompassing solutions (these
two *may be* necessary or *may be* important protocol extensions) to
address everything laid out in this doc. If that spirit is reflected that
would be great.

>
>
> 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
> >
[Uma]: Thx

> with Daniele) will follow shortly.
[Uma]: Ack.

> 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.
>
[Uma]: Sure.

> >   to enhancedVPN (which nicely documents how better underlay
> technologies can be effectively used with VPNs).
>
[Uma]: I made this comment after a long discussion privately with one of
the folks who is deploying the solutions. If he is willing, I shall put
together a document. Again, this would be one scenario for IETF network
slicing in the 5G deployments (in some segments of the network). Some
aspects are covered in
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility

>
> It may be, however, that you misunderstand the VPN+ work.
>
[Uma]: No question about that but I assure there are more folks and I am
really thankful for your response below.

> 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.
>
[Uma]: Excellent summary. But, it's important to separate underlay
capabilities and how those can be used with all sorts of VPNs.

> Does any of these work for you?
[Uma]: Maybe I will pick "support" (other terms you listed are fine too).
See below.

> 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
[Uma]: Much better. I guess, there is this notion of IETF slicing from the
consumer point of view represented in this document (aka consumer gets a
VPN with a logical part of the underlay) and hence it seems this document
is centered around (on this aspect) providing "that" VPN service with
underlay. Now, I seem to realize why it was heavily focused on VPN+. Some
of my comments are mostly from technology agnostic underlay perspective to
build the core slicing requirements.

> Good comment, but are you proposing anything in particular?
[Uma]: No, not really. This link is not part of the topology (PE-PE) is a
general case.  I am just saying this is an important piece for E2E slicing
solution else this would be the bottleneck for SLO fulfillment.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 27 Apr 2021 06:39:53 +0000

Hi Daniele, 

Please see some comments inline:

> From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
> Sent: Monday, April 19, 2021 5:14 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Teas] New Slicing revision: I-D Action:
> > Subject: RE: [Teas] New Slicing revision: I-D Action:
> > draft-ietf-teas-ietf-network- slices-01.txt
> >
> > Hi Daniele,
> >

Before listing draft-bestbar or slice aggregate as one of the "existing tools", its relationship with the enhanced VPN work needs to be clarified first. And since it is currently an individual document, maybe it is a little early to be considered as an "existing IETF tool"? 

Best regards,
Jie

> 
> >
> > 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.
> 
> [DC] Makes sense. It's not the scope of the framework to define solutions. An
> hook to existing work is more than enough. Maybe solution drafts might go
> into a more detailed analysis of how each solution can meet the requirements.
> 
> >
> > > (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.
> >
> > 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:
> >
> > draft-bestbar-teas-yang-slice- policy
> > internet- [email-masked]
> > 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.
> >