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

[Igor Bryskin <[e-mail]>]

Hi Adrian,
I agree on the architecture and technology agnostic NBI, but this is not what OTN slicing seems to be about. Why would it have NBI of its own, when the whole point is to have orchestrator to talk to all transport technologies in exact same way (the very definition of technology agnostic paradigm)?
I agree on term "OTN slice", if it is understood as a euphenism for "OTN tunnel" or a "set of OTN tunnels" (tabacco slice -》 cigar )
And yes, top down dynamic process must meet somewhere with bottom up pre-planned network building. The question is where in the multi-layer network this point of rendezvoux could realistically be ? If our experience with top down nulti-layer TE is of any indication, this is likely to be the boundary between the top  layer and the layer immediately under it. This would mean that whenever IP layer is in the stack, it would be the only one to face NS  NBI. I hope you can follow this logic.
Igor

Sent from Yahoo Mail on Android 
 
  On Thu, Mar 10, 2022 at 7:39 AM, Adrian Farrel<[e-mail]> wrote:   #yiv4963336221 #yiv4963336221 -- _filtered {} _filtered {}#yiv4963336221 #yiv4963336221 p.yiv4963336221MsoNormal, #yiv4963336221 li.yiv4963336221MsoNormal, #yiv4963336221 div.yiv4963336221MsoNormal {margin:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv4963336221 p.yiv4963336221msolistparagraph, #yiv4963336221 li.yiv4963336221msolistparagraph, #yiv4963336221 div.yiv4963336221msolistparagraph {margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv4963336221 span.yiv4963336221EmailStyle21 {font-family:sans-serif;color:windowtext;}#yiv4963336221 .yiv4963336221MsoChpDefault {font-family:sans-serif;} _filtered {}#yiv4963336221 div.yiv4963336221WordSection1 {}#yiv4963336221 _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 {}#yiv4963336221 ol {margin-bottom:0cm;}#yiv4963336221 ul {margin-bottom:0cm;}#yiv4963336221 
Hi Igor,

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

IB:. I think to achieve this it would take basic OTN service delivering non-IP client over p2p links, something OTN has been doing for decades.

  

[AF] Good we agree on the architecture.

I think that the slice orchestrator (or whatever you call the thing that composes the e2e slice) will make requests to the transport network using the slice service model. Thus, at the least, we need a way to map the slice service model requests into OTN p2p connectivity services.
   
   - 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.

IB: This includes not just OTN, of course,  but also flexE. microwave, OCh, physical fiber, lease line, PW and pretty much anything else that can deliver bits from A to B. To paraphrase my favorite Gert's question: what is not a transport slice according to the framework?

  

[AF] Agreed. Indeed, according to the 3GPP architecture, what is not a technology that can be made as a transport network and sliced?

[AF] Our only limit appears to be that we are the IETF so we are only slicing where IETF technologies are in use. Unless the dataplane is IP or MPLS, that seems to restrict us to cases where we are using an IETF control plane or IETF management structures (YANG models) to control the data plane.
   
   - 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.

IB: of course.
   
   - 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?

IB: As one Austrian guy said  "sometimes a cigar is just a cigar" and should be called cigar, rather than, say, tobaco slice );

Yes, it is not big deal if we stick to VNs, which normally are bottom up network building constructs. But it could become a rather big deal if one tries to engage OTN directly in the top down netwrk slicing process by, for example, creating VNs on the fly.

  

[AF] At some point, the top down service request has to meet the bottom up network engineering. If the Austrian’s neighbour (perhaps someone from Switzerland) comes into the shop and asks for a slice, the Austrian says, “Yes, of course, sir. What type of slice would you like?” And if the response is, “Tobacco,” does the Austrian laugh and say, “Don’t be ridiculous. Get out of my shop.” Or does he sell him a cigar while calling is a tobacco slice? 

  

>From my perspective, this is about generalising the top-down concept so that we have a common framework and technology-independent API. That has to be mapped to technologies (according to what technologies people actually want to support – no point in doing a mapping for NetBios?), and that is (I think) what lies behind the CCAMP OTN Slicing work.

  

Best,

Adrian