Subject: Re: [CCAMP] Interim discussions on OTN slicing

From: Aihua Guo <[email-masked]>
Date: Wed, 23 Feb 2022 12:16:48 -0500

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,

   - Realization of slicing is not limited only to some specific
      technologies but also others such as OTN
      - The terms and modeling structure are aligned with the definition in
      IETF network slicing

Thanks,

Aihua (on behalf of the co-authors)

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 25 Feb 2022 15:25:25 +0000 (UTC)

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 <[email-masked]> 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,

   - Realization of slicing is not limited only to some specific technologies but also others such as OTN
   - 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp