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

[Adrian Farrel <[e-mail]>]

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