Subject: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

From: <[email-masked]>
Date: Tue, 14 Jul 2020 09:08:11 +0100

Greetings TEAS,

For your reading pleasure we recently updated our ACTN applicability to network slicing I-D. 

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing
https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing

The tldr version, we updated the document to point to a candidate YANG model for transport network slicing (draft-wd-teas-transport-slice-yang). We also fixed some NITs and identified some additional/future work. 

As always we would love to hear from the WG participants. Did you find the I-D useful, not so useful, are we on the right track, what is missing? All feedback acknowledged and gratefully received. 

See you (virtually) soon. 

BR, Dan.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: 13 July 2020 20:47
To: Haomian Zheng <[email-masked]>; John Drake <[email-masked]>; Daniel King <[email-masked]>
Subject: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

A new version of I-D, draft-king-teas-applicability-actn-slicing-06.txt
has been successfully submitted by Daniel King and posted to the IETF repository.

Name:		draft-king-teas-applicability-actn-slicing
Revision:	06
Title:		Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing
Document date:	2020-07-13
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-king-teas-applicability-actn-slicing-06.txt
Status:         https://datatracker.ietf.org/doc/draft-king-teas-applicability-actn-slicing/
Htmlized:       https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing
Diff:           https://www.ietf.org/rfcdiff?url2=draft-king-teas-applicability-actn-slicing-06

Abstract:
   Network abstraction is a technique that can be applied to a network
   domain that utilizes a set of policies to select network resources
   and obtain a view of potential connectivity across the network.

   Network slicing is an approach to network operations that builds on
   the concept of network abstraction to provide programmability,
   flexibility, and modularity.  It may use techniques such as Software
   Defined Networking (SDN) and Network Function Virtualization (NFV) to
   create multiple logical or virtual networks, each tailored for a set
   of services share the same set of requirements.

   Abstraction and Control of Traffic Engineered Networks (ACTN) is
   described in RFC 8453.  It defines an SDN-based architecture that
   relies on the concept of network and service abstraction to detach
   network and service control from the underlying data plane.

   This document outlines the applicability of ACTN to transport network
   slicing in a Traffic Engineering (TE) network that utilizes IETF
   technology.  It also identifies the features of network slicing not
   currently within the scope of ACTN, and indicates where ACTN might be
   extended.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 14 Jul 2020 14:47:35 +0000

Hi Dan,

Extremely useful in my opinion.

Just a couple of comments from my side:

  *   Applicability ACTN to TE Network Slicing: does this imply that it is possible to do slicing also without TE?
  *   - "...indicates where ACTN might be extended." - Probably it's worth changing the scope of the draft. It's not just applicability but something more, something like applicability and gap filling?
  *   Terminology section: “The terms defined below are intended to give context and meaning for use in this document only and do not force wider applicability”. Maybe we can use terms within the scope of the document till we will have standard terms to replace them with. (draft-nsdt-teas-transport-slice-definition-03 could be the source). Others seems to be quite generic and not depending on network slicing.
  *   Transport network slice: Brave usage of the word “transport” 😊
  *   Section 2: requirements for network slicing – I would suggest to focus on “requirements for transport network slicing” instead. Moreover this is yet another topic which is covered from the NS DT. Probably this section would fit better into “draft-nsdt-teas-ns-framework-02” ?
  *   Section 3.2.4 – This is probably the most interesting part. What the service provider usually sells to a customer is a VPN and the service mapping functionality is used to bind a VPN to the TE infrastructure and hence meet the SLA/SLO requested. In the latest version of the TE service mapping draft we added the support for network models (L3NM and L2NM) in addition to the Service Models. This is to allow the operator to specify a binding request in the ACTN framework and not just the customer. The section might need to be updated to the latest version of the mapping draft (v04)

Cheers,

Daniele

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: den 14 juli 2020 10:08
To: [email-masked]
Subject: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

Greetings TEAS,

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing

BR, Dan.

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Sent: 13 July 2020 20:47

To: Haomian Zheng <[email-masked]<mailto:[email-masked]>>; John Drake <[email-masked]<mailto:[email-masked]>>; Daniel King <[email-masked]<mailto:[email-masked]>>

Revision:          06

Pages:                                         17

Abstract:

   extended.

The IETF Secretariat

_______________________________________________

Teas mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Jul 2020 17:44:08 +0100

Hi Daniele,

Adding my thoughts because, well, that’s what I do, sometimes.

It’s good to be talking about this slicing work on the WG list.

> Applicability ACTN to TE Network Slicing: does this imply that it is

> possible to do slicing also without TE?

I believe it is possible to slice a network without having TE. Some rudimentary examples exist in DSCP or in the way routers can be configured to partition the buffers/bandwidth for best-effort and TE traffic.

ACTN (of course?) is a TE technology and applies to TE networks. So this draft would apply to slicing of TE networks.

Probably (?) the TEAS working group develops TE technologies.

> "...indicates where ACTN might be extended." - Probably it's worth changing

> the scope of the draft. It's not just applicability but something more, something

> like applicability and gap filling?

Good question. It is possible that the authors intend to identify the gaps, write protocol documents to fill the gaps, and then convert the gap analysis into applicability statement. IOW, by the time the document becomes and RFC (that’s one for your grandchildren) there will be no gaps and it will be a ‘pure’ applicability statement.

> Terminology section: “The terms defined below are intended to give context

> and meaning for use in this document only and do not force wider applicability”.

> Maybe we can use terms within the scope of the document till we will have

> standard terms to replace them with. (draft-nsdt-teas-transport-slice-definition

> -03 could be the source). Others seems to be quite generic and not depending

> on network slicing. 

Right. At such time that the WG reaches consensus on slicing terminology, it would be wise for all WG documents and prospective WG documents to adopt the same terminology.

I think that what this document is saying is that it is using terminology for the sake of making it possible to understand the document. It looks to me that the authors are not trying to enter into the debate that the network slicing design team is likely having, although I’m willing to believe that the authors would be delighted if the DT adopted the terminology from this draft 😊

> Transport network slice: Brave usage of the word “transport” 😊

I can’t help agreeing! Although I like the way the fact of “transporting another service” is made clear. Thus, it is the use to which the slice is put that makes it a transport slice: it is not a question of the technology used to provide the slice.

> Section 2: requirements for network slicing – I would suggest to focus 

> on “requirements for transport network slicing” instead. Moreover this

> is yet another topic which is covered from the NS DT. Probably this

> section would fit better into “draft-nsdt-teas-ns-framework-02” ? 

Here I would disagree strongly. The document is about network slicing more generally (the definition is there just above the definition of transport network slice). Why should the WG limit itself to this restricted concept? The text is quite clear that the scope is limited to IETF technologies.

As to whether this text is picked up by other drafts, that’s an open question. 

> Section 3.2.4 – This is probably the most interesting part. What the service

> provider usually sells to a customer is a VPN and the service mapping

> functionality is used to bind a VPN to the TE infrastructure and hence meet

> the SLA/SLO requested.

I agree. See the VPN+ work.

> In the latest version of the TE service mapping draft we added the support

> for network models (L3NM and L2NM) in addition to the Service Models.

> This is to allow the operator to specify a binding request in the ACTN

> framework and not just the customer. The section might need to be

> updated to the latest version of the mapping draft (v04)

Yes, that is so.

And I think that there is more work coming from several people on “network slice as a service” which also might be categorized as an NBI for network slicing.

We should consider that the “customer” for a slice may be an internal organization of the service provider.

Best,

Adrian

-----Original Message-----
From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: den 14 juli 2020 10:08
To: [email-masked] <mailto:[email-masked]> 
Subject: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

Greetings TEAS,

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to TE Network Slicing  <https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing> https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing

BR, Dan.

-----Original Message-----

From:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> [email-masked]>

Sent: 13 July 2020 20:47

To: Haomian Zheng < <mailto:[email-masked]> [email-masked]>; John Drake < <mailto:[email-masked]> [email-masked]>; Daniel King < <mailto:[email-masked]> [email-masked]>

 

Revision:          06

Pages:                                         17

URL:             <https://www.ietf.org/internet-drafts/draft-king-teas-applicability-actn-slicing-06.txt> https://www.ietf.org/internet-drafts/draft-king-teas-applicability-actn-slicing-06.txt

Status:          <https://datatracker.ietf.org/doc/draft-king-teas-applicability-actn-slicing/> https://datatracker.ietf.org/doc/draft-king-teas-applicability-actn-slicing/

Htmlized:        <https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-06> https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-06

Htmlized:        <https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing> https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-slicing

Diff:            <https://www.ietf.org/rfcdiff?url2=draft-king-teas-applicability-actn-slicing-06> https://www.ietf.org/rfcdiff?url2=draft-king-teas-applicability-actn-slicing-06

Abstract:

   extended.

 

The IETF Secretariat

Teas mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 22 Jul 2020 01:44:55 +0000

Hi Dan, 
I'd like to share few thoughts form my reading of this document, mostly for clarifications:

- First thing that strikes me is: the things before chapter 3 are not related to ACTN only, and is common information that will benefit all. I'd strongly encourage to give broader relevance to requirements section.

- Out of curiosity, why do you define Resource and Infrastructure resource separately when you don't use them later in the document?

- In terminology part defining network slice as an agreement is an interesting choice (difficult for me to get used to), but since this is an ACTN world, why not call it a client network?

- I could only follow delivery model 3.2.3 in relation to transport slices. Could not grasp relevance of section 3.2.1 and 3.2.2 - are they not transport slices? 

- Even in 3.2.4, I understand the text explains the  mappings of Lx-service-models to ACTN but beyond that relationship to slices is not clear. This is very important and crux of ACTN applicability to slices. If you followed nsdt discussion, we were asked to remove it as an example of SBI. Because service models are consumer's view of the network. So if you explain relationship in terms of interface and use, that would be very useful.

- I can not differentiate between the usage of term network slice transport slice: - which one should be used when?  In nsdt we have a notion of higher-level orchestrator that interfaces with transport controller so it is not a problem there.

- one thing missing is a ACTN framework to TS-framework comparison.

This is a good contribution. I hope to see better alignment in time..
Thanks
Kiran

> Sent: Tuesday, July 14, 2020 1:08 AM
> To: [email-masked]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-king-teas-applicability-actn-
> slicing&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9f04f
> ca662e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637303109400397496&amp;sdata=4Eyq1sAw7Ow0MpVHiTvFFpMXLNmsILG
> pYD54SImHAAw%3D&amp;reserved=0
> 
> The tldr version, we updated the document to point to a candidate YANG
> model for transport network slicing (draft-wd-teas-transport-slice-yang). We
> also fixed some NITs and identified some additional/future work.
> 
> As always we would love to hear from the WG participants. Did you find the I-D
> useful, not so useful, are we on the right track, what is missing? All feedback
> acknowledged and gratefully received.
> 
> To: Haomian Zheng <[email-masked]>; John Drake
> <[email-masked]>; Daniel King <[email-masked]>
> URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Finternet-drafts%2Fdraft-king-teas-applicability-actn-slicing-
> 06.txt&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9f04f
> ca662e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637303109400397496&amp;sdata=Jx8IyUCQJ0RTzGWs%2F4tLuGbBbgJBUfb
> 2aX5gAcu7bA4%3D&amp;reserved=0
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-king-teas-applicability-actn-
> slicing%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9
> f04fca662e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C
> 0%7C637303109400407495&amp;sdata=aVfyA15howACcW%2BkLZAH%2B2I
> ORFAZEJtC5ANlZigy8Vk%3D&amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.i
> etf.org%2Fhtml%2Fdraft-king-teas-applicability-actn-slicing-
> 06&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9f04fca6
> 62e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37303109400407495&amp;sdata=6yWCeXEujIPIT8KaTLCXfiJvRstVQjTbj2FzXgr
> 6i6Q%3D&amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-king-teas-applicability-actn-
> slicing&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9f04f
> ca662e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637303109400407495&amp;sdata=ziekTnqxE9LwTHLwqa2cUgYSiCDnBkY5U
> 6xZexajf2A%3D&amp;reserved=0
> Diff:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl2%3Ddraft-king-teas-applicability-actn-slicing-
> 06&amp;data=02%7C01%7Ckiranm%40futurewei.com%7Cc25b2df4f9f04fca6
> 62e08d827cd28b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37303109400407495&amp;sdata=2FhfHfo7mFzcO1KAwi9dBYDChLaGjHpI3xp
> H624UZi8%3D&amp;reserved=0
> 
> Abstract:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> [email-masked]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fu
> turewei.com%7Cc25b2df4f9f04fca662e08d827cd28b9%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637303109400407495&amp;sdata=i1CyZvff
> WC%2B%2FwsbL3CkQ3T8LOuFw7wN3Kbb9UxLcexo%3D&amp;reserved=0