Re: [Teas-ns-dt] Draft mail to wg

Jimmy,

My point is that w/ the advent of the network slicing design team we now have multiple drafts where previously we only had the enhanced VPN draft, and that we should consider how we want to organize existing and new material between these drafts.  Given this, and given that we need to develop a draft that describes candidate technologies to support the instantiation of a transport slice, it seems natural to me to re-purpose the Enhanced VPN draft to be that draft.  (We also need a draft that describes how an enhanced VPN uses a transport slice, and for that I would suggest this draft:  https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-07.)

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 23, 2020 10:43 AM
To: John E Drake <jdrake@juniper.net>et>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Cc: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>rg>; teas-ns-dt@ietf.org
Subject: Re: [Teas-ns-dt] Draft mail to wg

Hi John,

I totally agree that the enhanced VPN framework draft was targeting at network slicing, while we chose the term enhanced VPN (maybe the short term VPN+ is more suitable) to make it more generic and also show its relationship with the existing technologies. The draft describes a framework of providing enhanced VPN services, which consists of both the overlay VPN and a subset of the underlay network to meet the enhanced service requirement. That said, network slice is mentioned several times in the document as the motivation and one important use case.

In that draft, the candidate technologies are described in section 5. While in section 3 and section 4, a list of requirements and a layered architecture are also provided.  Thus IMO this document is more than “candidate technologies to instantiate transport slices”, but we could say it is more focusing on the underlying network architecture and candidate technologies than the northbound interface.

Best regards,
Jie

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Monday, March 23, 2020 1:05 AM
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>; Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
Subject: RE: [Teas-ns-dt] Draft mail to wg

Oopsie.  To continue:

As I mentioned several months ago when I was tasked with mining the Enhanced VPN draft for material germane to the Transport Slice Framework draft, despite its title the former draft is really describing transport slices and not enhanced VPNs.  I.e., it describes what an enhanced VPN would require from the underlay network and describes what technologies might be used by the underlay network to meet those requirements.

So, my suggestion is to re-title the Enhanced VPN draft to something like ‘Candidate Technologies Needed to Instantiate Transport Slices’ and use it a the vehicle to provide a comprehensive analysis of these technologies in the context of providing a transport slice.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> On Behalf Of John E Drake
Sent: Sunday, March 22, 2020 12:54 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
Subject: Re: [Teas-ns-dt] Draft mail to wg

Jimmy,

As I mentioned several months ago when I was tasked with mining the Enhanced VPN draft
Sent from my iPhone

On Mar 22, 2020, at 11:42 AM, Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> wrote:

Hi Jari,

Thanks for preparing the mail to the WG. Please find some comments inline:

From: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Sunday, March 22, 2020 9:05 PM
To: teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
Subject: [Teas-ns-dt] Draft mail to wg

Suggested mail:

Subject: networking slicing design team results + call for feedback

Hi,

As you know, we’ve had a design team looking at how IETF VPN and TE technologies can be used to assist network slicing; to provide a framework [1]. The design team has been running for a couple of months, enough to have some first, very early results. We have two documents, one about definitions and another one about a framework of how slicing, underlying technologies, controllers, etc. fit together. The central concept is that one of a “transport slice”, which we believe would be useful as a component in various people building their networks. A transport slice is nothing magical, it is simply the service that many IETF technologies are already offering.

[Jie] Maybe what we want to show is transport slice is not a totally new thing, it is based on the service provided using many existing IETF technologies. As mentioned in next paragraph, “some enhancements will be needed”, the last sentence in the above paragraph could be more open so as to align with that statement.

It is important to understand that the design team is not here to develop new VPN/TE technologies, not here to focus on specific new characteristics that one may want from one’s VPNs, not here to define 5G slicing, not here to look at compute and services, and hopefully not here to boil the ocean. We’re also not done, as noted the documents that we have are early, and perhaps more importantly, there are still other things to develop. For instance, presumably one would like to have a data model or an interface with which one can request transport slices. Such an interface may partially exist already but the design team seems to believe that at least some enhancements will be needed. That’s all future work, either in the design team or as part of existing tech being improved. We also do not at the moment have a document that would point to all the relevant existing technologies that can be used to realise the framework or other frameworks across technologies for other reasons (e.g., enhanced-vpn that looked at enhanced isolation). Those are all forthcoming work as well.

[Jie] The enhanced-VPN framework draft looks at not only enhanced isolation, but also other requirements, such as performance guarantee, customized control and partly about the service management. Thus I’d suggest the text be changed to “e.g. enhanced-vpn framework that looks at some of the requirements and candidate technologies”.

Best regards,
Jie

At this point we’d love to get feedback on these documents though:

https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01__;!!NEt6yMaO-gk!VX1uuNBiwjSsMUOmBqDtbWKoy9IhdOgYNlkOy1MfCa6XJTb7GSZ-_S7aCx06nPQ$>
https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-nsdt-teas-ns-framework-01__;!!NEt6yMaO-gk!VX1uuNBiwjSsMUOmBqDtbWKoy9IhdOgYNlkOy1MfCa6XJTb7GSZ-_S7aTU1mOgM$>

Jari

[1] https://mailarchive.ietf.org/arch/msg/teas/jiHWXU_i5kK5BzjRffFbYnbZJfs/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/teas/jiHWXU_i5kK5BzjRffFbYnbZJfs/__;!!NEt6yMaO-gk!VX1uuNBiwjSsMUOmBqDtbWKoy9IhdOgYNlkOy1MfCa6XJTb7GSZ-_S7aQXPCMb0$>

--
Teas-ns-dt mailing list
Teas-ns-dt@ietf.org<mailto:Teas-ns-dt@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!VX1uuNBiwjSsMUOmBqDtbWKoy9IhdOgYNlkOy1MfCa6XJTb7GSZ-_S7a4GsWs3c$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!VX1uuNBiwjSsMUOmBqDtbWKoy9IhdOgYNlkOy1MfCa6XJTb7GSZ-_S7a4GsWs3c$>