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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2020 23:26:41 +0100

Hi TEAS,

As the debate over adoption of draft-nsdt-teas-transport-slice-definition
raging (I plan to pitch in on that soon), I wanted to remind the working
group about draft-king-teas-applicability-actn-slicing and ask the chairs if
they will consider that for adoption alongside the output of the Slicing
Design Team.

As you'll all be aware, ACTN is a key technology developed by this working
group that can be used for managing TE networks utilising many of the YANG
models developed in TEAS and elsewhere in the IETF. It closely follows SDN
architectures to provide a way for operators to provide services (and in
particular virtual network services) over their transport networks.

Enhanced VPNs (VPN+, also TEAS work) is about how basic VPN services can be
enhanced through the addition of service delivery objectives to represent a
service that turns out to look very much like network slicing.

It shouldn't be a surprise that ACTN is an appropriate tool for delivering
enhanced VPNs since they are a virtual network service.

What draft-king-teas-applicability-actn-slicing does is discuss the
applicability of ACTN to delivering network slicing services over TE
networks. It explains how you would build a slice, and it cross-references
the YANG models (in various states of development) that could provide the
information needed at the different interfaces.

While developing draft-king-teas-applicability-actn-slicing we obviously
needed to discuss terms and functions that are essential to an understanding
of network slicing. Some of these were borrowed from the enhanced VPN work,
which had previously borrowed them from an early version of this draft (what
comes around, goes around). It was not our intention to compete with the
Design Team work, but we needed this material in our document and we wrote a
lot of it way back in 2017 when we started the draft (somewhat before the
Design Team was formed).

There has been some debate about whether
draft-king-teas-applicability-actn-slicing is too limited because it can
only deliver slicing services over TE networks. That is a fine question, but
there is a strong argument that the act of slicing a network is only
possible through TE means whether those are implemented within the network
or in a centralised system. We might also ask whether TEAS is able to
address non-TE networks within its current charter.

If it turns out that there is WG preference for the terminology and language
used in the Design Team's documents then we would work out how to modify
draft-king-teas-applicability-actn-slicing. If, on the other hand, the WG
prefers the way we have expressed things then we would be please to see that
material find its way into a working group document. There would be two ways
to achieve that:
1. Leave it in draft-king-teas-applicability-actn-slicing and adopt that
draft
2. Modify the Design Team draft and reference it from
draft-king-teas-applicability-actn-slicing

Looking forward to your thoughts on this.

Best,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Sat, 29 Aug 2020 14:55:35 -0400

Hi Adrian,

On 8/28/2020 6:26 PM, Adrian Farrel wrote:
> ...

     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 29 Aug 2020 22:06:40 +0100

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 <[email-masked]> 
Sent: 29 August 2020 19:56
To: [email-masked]; [email-masked]
Cc: 'TEAS WG Chairs' <[email-masked]>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Hi Adrian,

Cheers,

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 31 Aug 2020 09:16:41 -0400

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.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Aug 2020 15:51:52 +0100

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 <[email-masked]> 
Sent: 31 August 2020 14:17
To: [email-masked]; [email-masked]
Cc: 'TEAS WG Chairs' <[email-masked]>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

Hi Adrian,

Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 31 Aug 2020 15:49:55 +0000

Hi Lou and Adrian, 

Sorry to chime in, here I'd like to provide some information about the removal of the ACTN applicability text from draft-ietf-teas-enhanced-vpn-06. 

During the review and update of the latest revision, the authors realized that the management plane section contains a lot of details about the service model applicability, which did not quite match with the depth and length about the candidate technologies description in other subsections, thus reducing the details while keeping the key information is considered the approach to achieve the balance between the candidate technologies subsections. 

In addition, based on the discussion in the NS-DT, it was indicated that the NBI interface and the corresponding data models will be the task of NS-DT in next step (following the definition and framework), thus it may be reasonable to leave the details about the NBI interface and data models described in the NS-DT documents or some dedicated documents, and have this topic fully discussed in the design team.

Thus that change is relatively independent from the respin of draft-king-teas-applicability-actn-slicing.

Based on the chairs' comments and suggestion in IETF 108, we understand that such change need review and discussion from the WG. We have listed that change and the reason in the mail of status update to the WG, and we'd appreciate comments from people regarding such change. Thanks.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Monday, August 31, 2020 9:17 PM
>      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.
> 
> 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+).
> 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).
> 
> > 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.
> >
> > 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.
> >
> > a. Pull material from draft-king-teas-applicability-actn-slicing into
> > draft-ietf-teas-enhanced-vpn and abandon
> > 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
> >
> > 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
> >
> > Subject: Re: [Teas] WG adoption of
> >       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
> > 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
> >>