Subject: [Teas] Network Slicing Design Team - Draft Charter

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 3 Sep 2019 17:35:34 -0500

WG,
    As discussed in Montreal we are forming a design team to help bring
focus to the many discussions we have been having on Network Slicing.  The
draft objectives and deliverables for the design team are outlined below.
At this time we’d like to ask for comments on this draft -- to be sent to
the WG list.  We would also like to ask any who are interested in
participating in the design team to send the WG chairs (cc’ed above) a
brief note expressing your interest, affiliation and relevant expertise.
Please do so within one week.  We expect the announcement of the DT
formation and membership one week after that.

While we appreciate your interest and willingness to contribute, please be
aware that not all  who volunteer will be included in the team.  All will
be able to participate in this work once we have a WG document on the topic
and, as always, the document progress through normal WG processing.  -- We
do note that the objective of the DT is to produce an initial draft and
there is no requirement for the authorship to be limited to or include all
DT members, and as usual, we expect a WG document to reflect actual
contribution to the work.

Thank you,
WG Chairs: Pavan, Lou

TEAS Network Slicing Design Team (Draft)

The topic of “Slicing” has received significant industry attention due to
its planned role in 5G networks.  (General background on slicing can be
found in [1] and [2].) Within the IETF the discussion has largely focused
on “Network Slicing” and to a lesser degree on Service Chaining
implications. [3] provides a sample list of related individual
contributions. Much of this work has focused on how the combination of VPN
and TE technologies can be used to deliver Network Slices. The TEAS Network
Slicing Design Team (NSDT) is being formed to develop a framework for
delivering Network Slicing using existing IETF technologies, and if and
where needed, possible extensions to those technologies - which may be in
the other working groups.  The reuse of definitions and technologies
developed by other SDOs is also in scope, although extensions to such will
be done in the appropriate SDO. An important early deliverable from the DT
will be a proposed definition of what is in-scope and what is out-of-scope
for the WG on this topic.

The Design Team will have flexibility to decide on how best to develop,
document and present its work. The DT will provide regular updates and
reports to the TEAS working group.  It will present an update on their
status and plans at IETF 106 (Singapore) - which will hopefully include an
initial discussion on scope.  For  IETF 107 (Vancouver) the goal for the DT
is an initial DT framework, and possibly draft, in time for discussion at
the meeting.  A stable Draft is targeted for discussion at IETF 108. Once
the draft is accepted as a working group document, it will progress per
TEAS working group normal process.

The DT mailing list will be set up with the membership of this list limited
to the design team and the chairs, but its archive will be open.  DT
meetings will be announced on the list and open to all.  The specific
workings, including meeting schedules, of the DT are the discretion of the
DT.
[1]
https://5g-ppp.eu/wp-content/uploads/2019/07/5G-PPP-5G-Architecture-White-Paper_v3.0_PublicConsultation.pdf
[2] http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-f10.zip
[3] Related IETF drafts
draft-ali-spring-network-slicing-building-blocks
draft-arkko-arch-virtualization
draft-bryant-rtgwg-enhanced-vpn
draft-defoy-netslices-3gpp-network-slicing
draft-dong-lsr-sr-enhanced-vpn
draft-dong-network-slicing-problem-statement
draft-dong-rtgwg-enhanced-vpn-protocol
draft-dong-spring-sr-for-enhanced-vpn
draft-dong-teas-enhanced-vpn
draft-drake-bess-enhanced-vpn
draft-eastlake-bess-enhance-evpn-all-active
draft-flinck-slicing-management
draft-galis-netslices-revised-problem-statement
draft-ietf-teas-enhanced-vpn
draft-king-teas-applicability-actn-slicing
draft-lee-rtgwg-actn-applicability-enhanced-vpn
draft-netslices-usecases
draft-peng-lsr-network-slicing
draft-qiang-coms-netslicing-information-model
draft-xuan-dmm-multicast-mobility-slicing
draft-zch-lsr-isis-network-slicing
draft-zhuang-bess-enhanced-vpn-auto-discovery

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 4 Sep 2019 06:46:02 +0000

Pavan and Lou,

The TEAS Network Slicing Design Team draft looks fine. Please add the following draft to your list.

https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00

Thanks,

Reza Rokui

From: Teas <[email-masked]> on behalf of Vishnu Pavan Beeram <[email-masked]>
Date: Wednesday, September 4, 2019 at 12:35 AM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Subject: [Teas] Network Slicing Design Team - Draft Charter

WG,
    As discussed in Montreal we are forming a design team to help bring focus to the many discussions we have been having on Network Slicing.  The draft objectives and deliverables for the design team are outlined below.  At this time we’d like to ask for comments on this draft -- to be sent to the WG list.  We would also like to ask any who are interested in participating in the design team to send the WG chairs (cc’ed above) a brief note expressing your interest, affiliation and relevant expertise.  Please do so within one week.  We expect the announcement of the DT formation and membership one week after that.

While we appreciate your interest and willingness to contribute, please be aware that not all  who volunteer will be included in the team.  All will be able to participate in this work once we have a WG document on the topic and, as always, the document progress through normal WG processing.  -- We do note that the objective of the DT is to produce an initial draft and there is no requirement for the authorship to be limited to or include all DT members, and as usual, we expect a WG document to reflect actual contribution to the work.

Thank you,
WG Chairs: Pavan, Lou

The topic of “Slicing” has received significant industry attention due to its planned role in 5G networks.  (General background on slicing can be found in [1] and [2].) Within the IETF the discussion has largely focused on “Network Slicing” and to a lesser degree on Service Chaining implications. [3] provides a sample list of related individual contributions. Much of this work has focused on how the combination of VPN and TE technologies can be used to deliver Network Slices. The TEAS Network Slicing Design Team (NSDT) is being formed to develop a framework for delivering Network Slicing using existing IETF technologies, and if and where needed, possible extensions to those technologies - which may be in the other working groups.  The reuse of definitions and technologies developed by other SDOs is also in scope, although extensions to such will be done in the appropriate SDO. An important early deliverable from the DT will be a proposed definition of what is in-scope and what is out-of-scope for the WG on this topic.

The Design Team will have flexibility to decide on how best to develop, document and present its work. The DT will provide regular updates and reports to the TEAS working group.  It will present an update on their status and plans at IETF 106 (Singapore) - which will hopefully include an initial discussion on scope.  For  IETF 107 (Vancouver) the goal for the DT is an initial DT framework, and possibly draft, in time for discussion at the meeting.  A stable Draft is targeted for discussion at IETF 108. Once the draft is accepted as a working group document, it will progress per TEAS working group normal process.

The DT mailing list will be set up with the membership of this list limited to the design team and the chairs, but its archive will be open.  DT meetings will be announced on the list and open to all.  The specific workings, including meeting schedules, of the DT are the discretion of the DT.  
[1] https://5g-ppp.eu/wp-content/uploads/2019/07/5G-PPP-5G-Architecture-White-Paper_v3.0_PublicConsultation.pdf
[2] http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-f10.zip<http://www.3gpp.org/ftp/Specs/archive/28_series/28.801/28801-f10.zip>
[3] Related IETF drafts

---

From: Kaippallimalil John <[email-masked]>
Date: Wed, 4 Sep 2019 13:35:14 +0000

Pavan, Lou,
For the 3GPP references, TR 28.801 is a technical report and not normative.
Please refer to TS 28.530 https://www.3gpp.org/ftp/Specs/archive/28_series/28.530/28530-f10.zip - which is a technical specification that covers concepts, use cases and requirements.

Also, please add the following to [3] – Related IETF drafts:
https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/
https://datatracker.ietf.org/doc/draft-lee-teas-actn-5g-transport/

BR,
John

This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.

From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, September 03, 2019 5:36 PM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>; BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]>
Subject: [Teas] Network Slicing Design Team - Draft Charter

WG,

Thank you,
WG Chairs: Pavan, Lou

[1] https://5g-ppp.eu/wp-content/uploads/2019/07/5G-PPP-5G-Architecture-White-Paper_v3.0_PublicConsultation.pdf<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F5g-ppp.eu%2Fwp-content%2Fuploads%2F2019%2F07%2F5G-PPP-5G-Architecture-White-Paper_v3.0_PublicConsultation.pdf&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C4c234a479a9844e3a13808d730bf1751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637031469601640971&sdata=l1mJIwzxo6sisWyceVTqio4knw6t6zUjTwYtqpQthho%3D&reserved=0>
[2] http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-f10.zip<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2Fftp%2F%2FSpecs%2Farchive%2F28_series%2F28.801%2F28801-f10.zip&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C4c234a479a9844e3a13808d730bf1751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637031469601640971&sdata=46QjCFZy%2BOJjU4PFx3jFGqP0NeNMjBgnOBvGWCbeCsk%3D&reserved=0>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Sep 2019 12:33:42 +0100

Hi Pavan, all,

Thanks for sharing this.

I’m a little confused and concerned with the overlap between this work and draft-ietf-teas-enhanced-vpn. While you list that document in your literature survey you don’t give any indication of how this DT should take that work into account.

I am also quite worried that you are effectively saying that the DT should set its own scope or, at least, suggest to the WG what the scope should be: “An important early deliverable from the DT will be a proposed definition of what is in-scope and what is out-of-scope for the WG on this topic,” and, “It will present an update on their status and plans at IETF 106 (Singapore) - which will hopefully include an initial discussion on scope.” That, to me, says that the WG should go and try to find some work that maybe needs doing and come back to the WG to suggest that the WG might like to do that work. Well, to be honest, we don’t need a DT for that – anyone can suggest meaningful work!

To add some context, I co-chaired both of the BoFs that the IETF has had on this topic (Netslices and COMS). Both found very considerable interest in the topic, but very poor agreement on questions like “what is slicing?”, “how much slicing is appropriate?”, and “what is the mapping between slicing in the 5G world and slicing in IP and sub-IP networks?” A good number of people at those meetings wanted to produce a big-picture architecture of slicing that embraced applications, the radio network, access networks, IP, and transport networks. I think that these meetings considerably advanced the understanding of network slicing in the IETF, but they failed to produce any constructive action for the IETF because the pictures were too large, and the potential work items too nebulous – the IETF works better when it can see specific technical problems that can be solved (by a working group) with a few documents of manageable length. A conclusion that could have been drawn from these BoFs was that, in order to advance the topic in the IETF, it was necessary to unpick the problem space and come up with concrete and targeted problems and solutions.

In view of this conclusion, a number of drafts were written such as draft-king-teas-applicability-actn-slicing and  <https://datatracker.ietf.org/doc/draft-dong-teas-enhanced-vpn/> draft-dong-teas-enhanced-vpn. These tried to show function that fits within the “network slicing” family, and to lean on existing technology to deliver that function. They resulted in the current WG draft, draft-ietf-teas-enhanced-vpn.

There are now a number of protocol proposals (draft-dong-spring-sr-for-enhanced-vpn, draft-dong-lsr-sr-enhanced-vpn, and draft-drake-bess-enhanced-vpn, etc.) that assume that it is worth putting energy into the enhanced VPN work, at least partly because it appears to be the consensus approach to network slicing in the IETF.

There was also a side meeting in Montreal on the same topic – I found myself as facilitator at the meeting. It was smaller and able to achieve more focus because of the existence of Enhanced VPNs and ACTN as technical topics we could talk around. Most of the attendees came from the Operations world, and the principle objective was to hear the voices of network operators on the topic of slicing. I think that we went into the meeting hoping that we might get some agreement about the solution technologies for enhanced VPN, but we found ourselves mainly talking about the scope and scale of enhanced VPN (What is it for? How many enhanced VPNs? How many sites?) in a series of questions not unlike those asked about network slicing.

So, my reading of your email is that:

*	The TEAS chairs agree that there is a lot of interested in the concept of network slicing
*	The chairs are putting together a group of people who can talk about this topic and report back to the WG
*	The group will be a closed group up until they come back to the WG at which time the group’s voice will not count for anything in particular
*	It will be hard for a dissenting voice outside the group to have influence because the group will arrive back at the WG with a “canned consensus”

One other observation: the netslices mailing list still exists for discussion of this topic.

Thanks,

Adrian

Sent: 03 September 2019 23:36

WG,

Thank you,
WG Chairs: Pavan, Lou

[2] http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-f10.zip <http://www.3gpp.org/ftp/Specs/archive/28_series/28.801/28801-f10.zip>

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 Sep 2019 17:24:34 -0400

Hi Adrian,

Sorry for the top post, but there seems to enough points being made that
a summarized response seems appropriate.

The context for our mail is the discussion from the last meeting of
forming a DT at the last meeting as a way to provide a bit more
structure to the discussions that have been taking place on supporting
network slicing using TE(AS) technology.  I think it's a fair comment
that the DT 'charter' be tightened up.  This is much the same point that
Jari made -- and as he said clearly the scope is leveraging TE and other
tools in the the IETF's TE tool kit.  As others (in documents) and you
allude to below,  much of what's need exists today or can be
accomplished using extensions of what exists.

The proposed  objective of the DT is to come up with a framework for the
TE solutions that can be used to support network slicing. To do this
work, we (chairs) believe there should be general agreement -- within
the WG -- of what is expected from this framework and this is why this
is the DT's first discussion topic with the WG.  To be clear, the point
is to ensure the DT is following a path that is aligned with the WG.  We
don't envision the WG taking on defining solutions, but they may
identify gaps that need to be filled.  Specific solutions/additions will
need to be worked  in the appropriate working groups, at a pace set by
those groups.

I'm sorry for not being clear on these points and hopefully this mail
helps, and we will certainly work to tighten up the design team
description with an aim to clarifying the above.  We will also make it
clear that the DT member identities, mailing list archive and working
meetings will be open to all.

Lou and Pavan

On 9/11/2019 7:33 AM, Adrian Farrel wrote:
>
> Hi Pavan, all,
>
> Thanks for sharing this.
>
> I’m a little confused and concerned with the overlap between this work 
> and draft-ietf-teas-enhanced-vpn. While you list that document in your 
> literature survey you don’t give any indication of how this DT should 
> take that work into account.
>
> I am also quite worried that you are effectively saying that the DT 
> should set its own scope or, at least, suggest to the WG what the 
> scope should be: “An important early deliverable from the DT will be a 
> proposed definition of what is in-scope and what is out-of-scope for 
> the WG on this topic,” and, “It will present an update on their status 
> and plans at IETF 106 (Singapore) - which will hopefully include an 
> initial discussion on scope.” That, to me, says that the WG should go 
> and try to find some work that maybe needs doing and come back to the 
> WG to suggest that the WG might like to do that work. Well, to be 
> honest, we don’t need a DT for that – anyone can suggest meaningful work!
>
> To add some context, I co-chaired both of the BoFs that the IETF has 
> had on this topic (Netslices and COMS). Both found very considerable 
> interest in the topic, but very poor agreement on questions like “what 
> is slicing?”, “how much slicing is appropriate?”, and “what is the 
> mapping between slicing in the 5G world and slicing in IP and sub-IP 
> networks?” A good number of people at those meetings wanted to produce 
> a big-picture architecture of slicing that embraced applications, the 
> radio network, access networks, IP, and transport networks. I think 
> that these meetings considerably advanced the understanding of network 
> slicing in the IETF, but they failed to produce any constructive 
> action for the IETF because the pictures were too large, and the 
> potential work items too nebulous – the IETF works better when it can 
> see specific technical problems that can be solved (by a working 
> group) with a few documents of manageable length. A conclusion that 
> could have been drawn from these BoFs was that, in order to advance 
> the topic in the IETF, it was necessary to unpick the problem space 
> and come up with concrete and targeted problems and solutions.
>
> In view of this conclusion, a number of drafts were written such as 
> draft-king-teas-applicability-actn-slicing and 
> <https://datatracker.ietf.org/doc/draft-dong-teas-enhanced-vpn/>. 
> These tried to show function that fits within the “network slicing” 
> family, and to lean on existing technology to deliver that function. 
> They resulted in the current WG draft, draft-ietf-teas-enhanced-vpn.
>
> There are now a number of protocol proposals 
> (draft-dong-spring-sr-for-enhanced-vpn, 
> draft-dong-lsr-sr-enhanced-vpn, and draft-drake-bess-enhanced-vpn, 
> etc.) that assume that it is worth putting energy into the enhanced 
> VPN work, at least partly because it appears to be the consensus 
> approach to network slicing in the IETF.
>
> There was also a side meeting in Montreal on the same topic – I found 
> myself as facilitator at the meeting. It was smaller and able to 
> achieve more focus because of the existence of Enhanced VPNs and ACTN 
> as technical topics we could talk around. Most of the attendees came 
> from the Operations world, and the principle objective was to hear the 
> voices of network operators on the topic of slicing. I think that we 
> went into the meeting hoping that we might get some agreement about 
> the solution technologies for enhanced VPN, but we found ourselves 
> mainly talking about the scope and scale of enhanced VPN (What is it 
> for? How many enhanced VPNs? How many sites?) in a series of questions 
> not unlike those asked about network slicing.
>
>   * The chairs are putting together a group of people who can talk
>     about this topic and report back to the WG
>   * The group will be a closed group up until they come back to the WG
>     at which time the group’s voice will not count for anything in
>     particular
>   * It will be hard for a dissenting voice outside the group to have
>     influence because the group will arrive back at the WG with a
>     “canned consensus”
>
> *From:*Teas <[email-masked]> *On Behalf Of *Vishnu Pavan Beeram
> *Sent:* 03 September 2019 23:36
> *To:* TEAS WG <[email-masked]>
> *Cc:* TEAS WG Chairs <[email-masked]>; BRUNGARD, DEBORAH A 
> (ATTLABS) <[email-masked]>
> *Subject:* [Teas] Network Slicing Design Team - Draft Charter
>
> WG,
>
>     As discussed in Montreal we are forming a design team to help 
> bring focus to the many discussions we have been having on Network 
> Slicing.  The draft objectives and deliverables for the design team 
> are outlined below.  At this time we’d like to ask for comments on 
> this draft -- to be sent to the WG list.  We would also like to ask 
> any who are interested in participating in the design team to send the 
> WG chairs (cc’ed above) a brief note expressing your interest, 
> affiliation and relevant expertise.  Please do so within one week.  We 
> expect the announcement of the DT formation and membership one week 
> after that.
>
> While we appreciate your interest and willingness to contribute, 
> please be aware that not all  who volunteer will be included in the 
> team.  All will be able to participate in this work once we have a WG 
> document on the topic and, as always, the document progress through 
> normal WG processing. -- We do note that the objective of the DT is to 
> produce an initial draft and there is no requirement for the 
> authorship to be limited to or include all DT members, and as usual, 
> we expect a WG document to reflect actual contribution to the work.
>
> Thank you,
> WG Chairs: Pavan, Lou
>
> The topic of “Slicing” has received significant industry attention due 
> to its planned role in 5G networks.  (General background on slicing 
> can be found in [1] and [2].) Within the IETF the discussion has 
> largely focused on “Network Slicing” and to a lesser degree on Service 
> Chaining implications. [3] provides a sample list of related 
> individual contributions. Much of this work has focused on how the 
> combination of VPN and TE technologies can be used to deliver Network 
> Slices. The TEAS Network Slicing Design Team (NSDT) is being formed to 
> develop a framework for delivering Network Slicing using existing IETF 
> technologies, and if and where needed, possible extensions to those 
> technologies - which may be in the other working groups. The reuse of 
> definitions and technologies developed by other SDOs is also in scope, 
> although extensions to such will be done in the appropriate SDO. An 
> important early deliverable from the DT will be a proposed definition 
> of what is in-scope and what is out-of-scope for the WG on this topic.
>
> The Design Team will have flexibility to decide on how best to 
> develop, document and present its work. The DT will provide regular 
> updates and reports to the TEAS working group.  It will present an 
> update on their status and plans at IETF 106 (Singapore) - which will 
> hopefully include an initial discussion on scope.  For  IETF 107 
> (Vancouver) the goal for the DT is an initial DT framework, and 
> possibly draft, in time for discussion at the meeting.  A stable Draft 
> is targeted for discussion at IETF 108. Once the draft is accepted as 
> a working group document, it will progress per TEAS working group 
> normal process.
>
> The DT mailing list will be set up with the membership of this list 
> limited to the design team and the chairs, but its archive will be 
> open.  DT meetings will be announced on the list and open to all.  The 
> specific workings, including meeting schedules, of the DT are the 
> discretion of the DT.  
> [1] 
> [2] 
> http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-f10.zip 
> <http://www.3gpp.org/ftp/Specs/archive/28_series/28.801/28801-f10.zip>
> [3] Related IETF drafts