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

[Lou Berger <[e-mail]>]

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 
> draft-dong-teas-enhanced-vpn 
> <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.
>
> 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
>
>