Re: [CCAMP] Interim discussions on OTN slicing

[Daniele Ceccarelli <[e-mail]>]

Aihua, Igor, all,

Thanks for progressing the discussion.
In an effort to try putting together the questions for TEAS this is what I summarized from the discussion.


  *   Is realization of slicing limited only to upper layers in the networks in a top-down process, where the lower layers are supposed to offer bottom-up network building capabilities (via P2P data links for higher layer clients) ? Or is it extended to the lower layers such as OTN (and potentially WDM, microwave etc)?
  *   Are the terms and modeling structure used in https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-yang-otn-slicing-00.txtare aligned with the ones defined in IETF network slicing?



Anything else we should add? Personally I would suggest to add something like:

  *   What needs to be added to ACTN VNs to have network slicing at the OTN layer?


Thanks
Daniele



From: Igor Bryskin <[e-mail]>
Sent: den 25 februari 2022 16:25
To: CCAMP <[e-mail]>rg>; [e-mail]; Aihua Guo <[e-mail]>
Subject: Re: [CCAMP] Interim discussions on OTN slicing

Aihua and All,

As I mentioned during the meeting, network slicing is inherently top-down emerging process aiming at realization of various connectivity constructs of different types and complexity levels that guarantee agreed upon SLOs through the lifetime of a network slice.  OTN, being a transport layer, can only offer bottom-up network building capabilities via realization of p2p data links for higher layer clients. This is the only thing a transport layer has been doing and is expected to be doing in the NS framework.

Consider, for example, an application requiring a p2mp distribution and asking for a network slice. While implementing required slice, network's IP layer may request help from the underlying OTN, but this help should not be understood as OTN slicing (which would be the case, for example, if IP layer was attempting to map the required p2mp tree onto a p2mp connection established in OTN). Rather, IP, when seeing that it does not have enough resources in IP layer to satisfy the request, may ask from the OTN (and because IP may span multiple independent OTN networks and not just OTNs, but transport networks of different types, including not involving OTN layer at all, but other transports such as FlexE, microwave, etc.) to enrich the IP topology with additional IP links supported by the underlying transport layer tunnels. Such additions are not OTN (or other transport) slices, rather, they are additional NRPs (Network Resource Partitions) as Pavan's, Tarek's and Co. ns-packet-slicing draft correctly defines.

My last point was that if WG decides to go forward with the work along currently defined lines, WG should be prepared to take on slicing in all other transport layers, as we did with topologies, tunnels, etc. I believe this is unnecessary - ACTN has already defined (great deal if not all) what is needed to support the network slicing by transport networks.

Cheers,
Igor

On Wednesday, February 23, 2022, 12:17:57 PM EST, Aihua Guo <[e-mail]<mailto:[e-mail]>> wrote:


Hi CCAMPers, Chairs,


Thank you for organizing and participating in the interim meeting for OTN slicing. We have had some further discussions on the weekly calls and here are the main points we draw from those discussions.



·        There is significant interest from the WG to progress the work for OTN slicing.

·        Most people believe the work for OTN slicing is consistent with the TEAS NS framework and is supported by the use cases described in the IETF NS framework as well as in this draft.

·        Most of the questions raised in the interim are not specific to OTN slicing but are more fundamental towards TEAS network slicing. The agreement from the interim, to our understanding, is to raise those questions to TEAS for addressing.

·        Since TEAS has already made the consensus to work on network slicing defined by the IETF NS framework, we think it is more appropriate for people who have concerns to challenge TEAS, as an individual, on those fundamental decisions. If TEAS decides to change the terms and scope on network slicing, then OTN slicing will follow suit and update accordingly.



Therefore, in our view a liaison to TEAS may not be needed at this point. However, if the chairs consider so then we suggest to confirm that our view is correctly aligned with the current TEAS work on network slicing. Specifically,

o   Realization of slicing is not limited only to some specific technologies but also others such as OTN

o   The terms and modeling structure are aligned with the definition in IETF network slicing



Thanks,

Aihua (on behalf of the co-authors)
_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp