Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Thanks Lou,

I have yet to review draft-nsdt-teas-ns-framework and that may help answer some of this. A quick scan shows that that draft dedicates just over two pages to the topic of ACTN where draft-king-teas-applicability-actn-slicing has about 14 pages of text. So there is certainly some additional material that could find a home somewhere (or be deleted). That certainly fits with your questions (a) and (b), with the alternative being to strip text from draft-nsdt-teas-ns-framework leaving a pointer.

More on that, I suppose, when I review draft-nsdt-teas-ns-framework. But if the result is us asking to include a further 10 pages on ACTN in the slicing framework, I hope you'd agree that that would unbalance that document. In that case, it might be more reasonable to have separate documents.

You say:

> This is basically the same difference as exists between *what*
> is being done (i.e., network slicing), versus *how* it's being
> done (e.g., VPN+).

This is not my reading of VPN+ from the framework document, but I'd agree that there is some ambiguity. This is the same ambiguity that arises in a lot of the network slicing discussion (I am currently finding it in draft-nsdt-teas-transport-slice-definition which I am reviewing for the WG adoption poll). The problem is common in the IETF: we are not good as separating discussions of a service with the details of how a service is delivered. 

We saw this quite a bit in the L3SM and L2SM discussions where there were repeated pushes to include features that would have been controls on how the network delivered the service rather than on what behavior the client wanted to see.

With VPNs, part of the problem is that we have always focused more on the protocol means of delivering the service (for example, BGP/MPLS) when we have spoken about "VPNs". Thus, it is "only natural" to hear "enhanced VPN" and think it must be a discussion about how a network enhances its protocol mechanisms to deliver an enhanced service. But, in my opinion, the VPN+ framework is more focussed on the additional service parameters that can be requested (pages 3-18 on overview, requirements, and architecture) and only provides pointers to the "candidate technologies" (pages 19-29). 

With network slicing there appears to be a tension between discussions of what a slice is and how it is used, versus ways of delivering network slicing. 

In both places, the tension causes confusion in discussion, allows particular technology solutions to be pushed to prominence in advance of proper consideration of the alternatives, and results in the sort of discussion we are having.

There are a number of protocol drafts describing how to deliver enhanced VPNs:
- draft-dong-6man-enhanced-vpn-vtn-id
- draft-dong-idr-bgpls-sr-enhanced-vpn
- draft-dong-lsr-sr-enhanced-vpn
- draft-dong-spring-sr-for-enhanced-vpn
- draft-drake-bess-enhanced-vpn
- draft-zhuang-bess-enhanced-vpn-auto-discovery
Just as new work will be developed to enable delivery of enhanced VPN, I expect new work will describe how to deliver network slices. 

But I think it is very important to keep the solutions material out of the requirements/framework documents. That's what draft-king-teas-applicability-actn-slicing is trying to do for network slicing.

Now back to reviewing draft-nsdt-teas-transport-slice-definition

Best,
Adrian
-----Original Message-----
From: Lou Berger <lberger@labn.net> 
Sent: 31 August 2020 14:17
To: adrian@olddog.co.uk; teas@ietf.org
Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Hi Adrian,

     As a general principle, I believe that if there is a suitable WG 
document for text sent to the list or contributed via an individual 
draft that such text should be incorporated into the WG document.

In this case, since we had/have ACTN applicability statements in both 
the draft-ietf-teas-enhanced-vpn and the draft-nsdt-teas-ns-framework.  
While the latter is not yet a WG document, the intent to issue an 
adoption call has been stated for a while.  (Extended IPR call completed 
last week, and adoption call just issued.)

So, I think it is reasonable to ask (a) what additional information is 
provided in draft-king-teas-applicability-actn-slicing and (b) can this 
additional information be reasonable incorporated into those documents.

WRT to your specific questions:

> - Is there a substantive difference between VPN+ and network slicing?
My reading of the current documents is that the network slicing allows 
for different specific technology solutions.  In other words, network 
slicing *can* be implemented by VPN+, but can also be implemented using 
other solutions.  This is basically the same difference as exists 
between *what* is being done (i.e., network slicing), versus *how* it's 
being done (e.g., VPN+).
> - Do we want to describe how to use ACTN for network slicing?

Given the inclusion of section 4 in the framework document, I'd say 
yes.  Also with the adoption call open, I think this is a great time for 
the authors of draft-king-teas-applicability-actn-slicing to voice that 
additional text  should be added to the framework document (with proper 
attribution).

Thank you for the discussion and usual good work on 
draft-king-teas-applicability-actn-slicing.

Lou

On 8/29/2020 5:06 PM, Adrian Farrel wrote:
> Hi Lou,
>
> Just to be clear, text was not removed from draft-ietf-enhanced-vpn and moved to draft-king-teas-applicability-actn-slicing.
>
> draft-king-teas-applicability-actn-slicing pre-dates the enhanced VPN work and only lapsed when the enhanced VPN draft was brought to TEAS from RTGWG, and some (a lot?) of the same material was brought into the enhanced VPN draft.
>
> But I think you bring out three good points for discussion:
>
> 1. Is enhanced VPN sufficiently equivalent to network slicing to mean that discussing "realisation of VPN+ using ACTN" is a duplication of discussing "applicability of ACTN to network slicing"? My opinion is that when viewed at the service level, VPN+ and network slicing are very, very similar. However, despite having the enhanced VPN framework that described network slicing, the working group decided it wanted a network slicing design team. That team has not come back with a statement that the two concepts are very similar and has, in fact, produced its own framework for slicing that might (or might not) overlap with a current working group draft.
>
> 2. Should draft-ietf-teas-enhanced-VPN go in to details on technologies that can deliver VPN+ or should it focus on describing the function and architecture that is an enhanced VPN? The current section 5 ("Candidate Technologies") gives a very brief description of the different network and management technologies that could be used, and highlights areas for future work, but it does not dig deep into solutions. Indeed, there are a number of related solutions drafts in other working groups (LSR, BESS, SPRING,...) that set out more detailed solutions work. In that respect, the old sections 5.6.1 and 5.6.2 were overly detailed compared to the rest of section 5, and removing text seems to have been a reasonable thing to do.
>   
> 3. How many is too many Informational documents? While the various VPN+ solutions drafts in other WGs are marked as Standards Track, it is a strangeness of where we are with ACTN that there is already and architecture and there are already YANG models (done or being worked on) that address all of the protocol needs. All that a document requires to do is show which of those models to use where and when in order to enable support for network slicing using ACTN, and that makes the document Informational. Once upon a time it was quite popular to write "cookbook" style Informational RFCs that helped people work out how to pull together bits of technology and build systems.
>
> Depending on the discussion of these three questions we could:
> a. Pull material from draft-king-teas-applicability-actn-slicing into draft-ietf-teas-enhanced-vpn and abandon draft-king-teas-applicability-actn-slicing
> b. Adopt draft-king-teas-applicability-actn-slicing and publish both it and draft-ietf-teas-enhanced-vpn
> c. Abandon the work of the network slicing design team folding new text into draft-ietf-teas-enhanced-vpn
> d. Adopt and publish lots of documents
> e. Any combination of the above
>
> I think it is reasonable to ask the WG:
> - Is there a substantive difference between VPN+ and network slicing?
> - Do we want to describe how to use ACTN for network slicing?
>
> I don't think it is reasonable to ask the WG:
> - What documents do you want to publish to achieve all of this?
> This is my belief because the WG is focused on technology not the niceties of publication. Actually, you either have to take the documents that people are working on, or you (as chairs) have to tell us what documents we should be working on (to which me might, of course, object :-)
>
> Lots of fun?
>
> Best,
> Adrian
>
> -----Original Message-----
> From: Lou Berger <lberger@labn.net>
> Sent: 29 August 2020 19:56
> To: adrian@olddog.co.uk; teas@ietf.org
> Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
> Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing
>
> Hi Adrian,
>
> On 8/28/2020 6:26 PM, Adrian Farrel wrote:
>> ...
>>
>> Looking forward to your thoughts on this.
>       As we (chairs) mentioned to you off-list, before we can talk about
> adoption of this document we still have the issue of working through the
> discussion at the last meeting.  Specifically the text that was removed
> from the WG document ( draft-ietf-teas-enhanced-vpn) that is largely
> present in this document.  My question is: assuming the text in is
> restored from draft-ietf-teas-enhanced-vpn-05, are there one or more
> suitable existing (or candidate) WG documents that could be a home for
> the remaining valuable text that is currently in
> applicability-actn-slicing document? -- after all how many information
> documents do we really need on this topic....
>
> I think this is a question not only for you and your coauthors, but also
> for the WG as a whole.
>
> Cheers,
>
> Lou
>
>> Best,
>> Adrian
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>