Re: [CCAMP] Interim discussions on OTN slicing

[Igor Bryskin <[e-mail]>]

Hi Daniele,
I would  add the following questions:1. According to the NS framework what is the minimum X has to support to be called IETF network slice? Specifically,  is a single physical fiber or a microwave link or a PW  is a slice? Is any collection of thereof is a slice?
2. Is it Ok for a IETF NS  to support only connection oriented p2p connectivity constructs or other connectivity types defined in the framework, such as p2mp , is a MUST?
3. How multi-layer slice hierarchy is supposed to work in the cases where the slices could not be neatly stacked because, for example, a higher layer (IP) slice realization spans multiple independent transport layer networks of different types?
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Tue, Mar 1, 2022 at 4:07 AM, Daniele Ceccarelli<[e-mail]> wrote:   #yiv9727637989 #yiv9727637989 -- _filtered {} _filtered {} _filtered {} _filtered {}#yiv9727637989 #yiv9727637989 p.yiv9727637989MsoNormal, #yiv9727637989 li.yiv9727637989MsoNormal, #yiv9727637989 div.yiv9727637989MsoNormal {margin:0cm;font-size:12.0pt;font-family:New serif;}#yiv9727637989 a:link, #yiv9727637989 span.yiv9727637989MsoHyperlink {color:blue;text-decoration:underline;}#yiv9727637989 p.yiv9727637989MsoListParagraph, #yiv9727637989 li.yiv9727637989MsoListParagraph, #yiv9727637989 div.yiv9727637989MsoListParagraph {margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:36.0pt;font-size:12.0pt;font-family:New serif;}#yiv9727637989 p.yiv9727637989msonormal, #yiv9727637989 li.yiv9727637989msonormal, #yiv9727637989 div.yiv9727637989msonormal {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New serif;}#yiv9727637989 span.yiv9727637989EmailStyle20 {font-family:sans-serif;color:windowtext;}#yiv9727637989 .yiv9727637989MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv9727637989 div.yiv9727637989WordSection1 {}#yiv9727637989 _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}#yiv9727637989 ol {margin-bottom:0cm;}#yiv9727637989 ul {margin-bottom:0cm;}#yiv9727637989 
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 inhttps://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]> 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]
https://www.ietf.org/mailman/listinfo/ccamp