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

[Adrian Farrel <[e-mail]>]

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.

 

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

 

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 <[e-mail] <mailto:[e-mail]> > On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: den 14 juli 2020 10:08
To: [e-mail] <mailto:[e-mail]> 
Subject: [Teas] FW: New Version Notification for draft-king-teas-applicability-actn-slicing-06.txt

 

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> 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:  <mailto:[e-mail]> [e-mail] < <mailto:[e-mail]> [e-mail]>

Sent: 13 July 2020 20:47

To: Haomian Zheng < <mailto:[e-mail]> [e-mail]>; John Drake < <mailto:[e-mail]> [e-mail]>; Daniel King < <mailto:[e-mail]> [e-mail]>

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

   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

 

 

 

_______________________________________________

Teas mailing list

 <mailto:[e-mail]> [e-mail]

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