Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

[Jeff Tantsura <[e-mail]>]

From the very beginning of this work we have clearly said that the scoop is wider than 5G slicing however they are one of the driving segments behind this work and their use cases are rather important. There are many other segments that would benefit from this work equally.

Cheers,
Jeff

> On Mar 9, 2022, at 09:01, Adrian Farrel <[e-mail]> wrote:
> 
> 
> Hi Daniele,
>  
> I appreciate your call for additional voices.
>  
> If, as you say, OTN already supports slicing with existing tools, then what is needed is an applicability statement “Addressing Network Slice Service Requests with an OTN” and that will ‘simply’ point up the existing tools and how the YANG modules are mapped. If, during that work, it is found that there are pieces missing (see also draft-ietf-teas-applicability-actn-slicing) then the document will need to contain more work.
>  
> I suspect that the authors of the ‘OTN slicing’ document believe that they have got ahead of us here by already discovering some missing pieces which they are going on to address. In that case, all that is needed is for them to ‘back-fill’ but describing how it fits together and why those pieces are necessary.
>  
> In response to Igor’s series of emails:
> If a 5G RAN is supported over an OTN then the concept of an e2e slice requires that there is something that can be called a transport network slice supported by the OTN.
> If the IETF Network Slicing Service YANG module is agnostic of the underlay network, then it should be possible for any network technology to have a go at supporting it.
> If a vendor does not want to implement or an operator does not want to support slicing over an OTN, that is a free choice.
> If the concept of slicing an OTN is no different from building a VN or a set of LSPs in that network, why is this whole thing a big deal?
>  
> Cheers,
> Adrian
>  
> From: Daniele Ceccarelli <[e-mail]> 
> Sent: 09 March 2022 10:42
> To: Igor Bryskin <i_bryskin=[e-mail]>; jdrake=[e-mail] <[e-mail]>; [e-mail]; 'TEAS WG' <[e-mail]>; CCAMP <[e-mail]>
> Subject: RE: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
>  
> Hi Igor,
>  
> I believe that OTN already supports network slicing today via existing tools (OTN TE tunnels, OTN ACTN VNs…etc), that why I don’t think we need to label it as OTN slicing (but this is just my personal opinion, CCAMP consensus seems to be different). Hence my answer would be yes to all of your questions.
>  
> It would be great to hear someone else’s opinion on both lists.
>  
> Cheers,
> Daniele 
>  
> From: Igor Bryskin <i_bryskin=[e-mail]> 
> Sent: den 8 mars 2022 14:10
> To: jdrake=[e-mail] <[e-mail]>; [e-mail]; 'TEAS WG' <[e-mail]>; CCAMP <[e-mail]>; Daniele Ceccarelli <[e-mail]>
> Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
>  
> Hi Daniele,
>  
> As you understand, I suggested to clarify NS framework's position and (ideally) narrow it's scope in two dimensions:
>  
> 1. application-wise (to 5G);
> 2. network-layer -wise (to IP)
>  
> Yes, TEAS has clearly rejected my proposal on 1. to be able to not overlook needs of other potential users, such as Enhanced VPNs, on-line gaming, IPTV, etc. I appreciate that. Despite no one so far identified an element in the framework that is not needed for 5G but is needed ,say, for gaming, such things might come up in the future.
>  
> But I didn't see much rejection or even resistance on 2.  Some (e.g. Gyan) expressed understanding of the concerns and openness to resolve them. Yes, it is unfair to dismiss OTN slicing by limiting framework to 5G, but it is equally unfair to justify it just because the framework intends to be open to other applications, such as gaming.
>  
> So, I think it is a good time to ask TEAS your questions. My main questions are:
> 1. Is one or a collection of several OTN TE tunnels is a network slice?
> 2. Is connection-oriented p2p  connectivity support is sufficient for X to be called network slice?
> 3. Several days ago Adrian defined NS service (how the NS is seen by a customer)  as a collection of connectivity constructs of various types and complexity levels. Can OTN deliver such a service?
>  
>  
> I appreciate very much the discussions . Thanks a lot to all involved.
>  
> Cheers,
> Igor
>  
> On Tuesday, March 8, 2022, 04:10:35 AM EST, Daniele Ceccarelli <daniele.ceccarelli=[e-mail]> wrote:
>  
>  
> Hi Igor,
> 
>  
> 
> (adding CCAMP as this is becoming a cross-wg discussion)
> 
>  
> 
> I get your point but it doesn’t seem fair to me to limit network slicing to 5G just to deprecate slicing at other layers. If there are other technical reasons to do so (some of which you already brought up) that’s fine, but I don’t think we should limit network slicing to 5G.
> 
> Moreover I’ve seen quite a lot of support in TEAS not to limit network slicing to 5G (obviously not my call).
> 
>  
> 
> Cheers,
> Daniele 
> 
>  
> 
> From: Igor Bryskin <i_bryskin=[e-mail]> 
> Sent: den 7 mars 2022 19:03
> To: Daniele Ceccarelli <[e-mail]>; Daniele Ceccarelli <[e-mail]>; jdrake=[e-mail] <[e-mail]>; [e-mail]; 'TEAS WG' <[e-mail]>
> Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
> 
>  
> 
> Daniele,
> 
>  
> 
> We all agreed that OTN  does not bring anything new into 5G that, for example,  was not happening  in 4G. OTN slicing work is motivated in some way, at least, because NS framework stipulates that the framework  is not limited to 5G. In fact, it seems to be not limited to anything (application -wise or layering -wise) to a point that it is not really clear what could not be considered a network slice.
> 
>  
> 
> However,  If the framework was focused on 5G (ideallt going even further and stating  that said 5G style network slicing happenning in IP layer only, which I believe is the case) ,  OTn slicing would have nothing to do with the framework (and the term  slicing) and would have to rely on its own merits ( which,  as you mentioned, you have doubts about yourself) and also  explain why it coincides in time with NS work triggered and inspired entirely by 5G.
> 
>  
> 
> Cheers,
> 
> Igor
> 
> Sent from Yahoo Mail on Android
> 
>  
> 
> On Mon, Mar 7, 2022 at 12:01 PM, Daniele Ceccarelli
> 
> <daniele.ceccarelli=[e-mail]> wrote:
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas