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

["Adrian Farrel" <[e-mail]>]

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

 

From: Teas <[e-mail]> On Behalf Of Vishnu Pavan Beeram
Sent: 03 September 2019 23:36
To: TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>; BRUNGARD, DEBORAH A (ATTLABS) <[e-mail]>
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

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