Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03

[Adrian Farrel <[e-mail]>]

Hello all,

 

Thanks to the authors for trying to pull together the different points that have been raised. That’s a useful way to understand where we are. Hopefully it will help the chairs work out what to do next.

 

Additional thoughts in line…

 

Adrian

 

From: CCAMP <[e-mail]> On Behalf Of Aihua Guo
Sent: 25 January 2022 18:46
To: Daniele Ceccarelli <[e-mail]>
Cc: CCAMP <[e-mail]>; Fatai Zhang <zhangfatai=[e-mail]>
Subject: Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03

 

Hi Daniele, Fatai, Reza, et.al <http://et.al> ,

 

Thank you all for the comments. We have received support for WG adoption as well as concerns/questions regarding the scope and terminologies, particularly the term "OTN slicing" used with this draft. These comments are always very helpful, and we would like to summarize the comments and share some collective responses below.

 

The main open points of these comments include:

Q: The use cases described in the draft are useful. However, the term "slice" is conflated. Why not change the term "OTN slicing" to "OTN service"? (Joel & Daniele)

A: According to the descriptions in the IETF NS framework document:

-         Network slice service (what the user asks for and operates with, as described in section 3.2)

-         Network slice (how the network resources are managed by the network, as described in section 3.1)

Accordingly, in the context of OTN there are scenarios where OTN technology-specific services require OTN network slices. Below are a few of the examples:

Section 2 of the draft describes OTN services that benefit from OTN network slices and we notice that the OTN wholesale (section 2.3) and co-sharing of OTN infrastructure (section 2.2) are also mentioned in the Framework for IETF network slices. Since these services are OTN technology specific, they require an OTN technology-specific slice and cannot rely on the technology-agnostic IETF network slices, otherwise the OTN technology-specific parameters requested by the user will be lost in the workflow.

Another example is a 4K HD service using baseband video/fiber channel directly over OTN ((non-IP). In this case the orchestrator can request an OTN technology-specific slice from an OTN-SC with L1-specific SLOs/SLEs.

 

I think that part of the problem in this discussion is that the term slice has been interpreted by some people (possibly in the marketing departments) as implying some kind of magic and sophisticated wizardry. But I don’t think it is!

 

Although I am still not happy with the text in draft-ietf-teas-ietf-network-slices, that document gives us a good scoping definition of the network slice and network slice service where the former is the arrangement of network resources in order to deliver the latter. So all this document is saying is that there are use cases where it is useful to partition the optical resources in the network to provide a set of connections that guarantee SLOs and SLEs as requested by the customer. 

 

It may be that some of us like to discuss that partitioning as an L1VPN or a virtual network or a set of L1 connections. That’s OK. But in the “modern jargon ” what is going on is a request for a network slice service and an arrangement of network resources to provide a network slice.

 

I can’t get hung up on the terminology.

 

Q: Network slicing should stop at the IP layer (Igor)

A: First, there is no such restriction described in the TEAS NS framework draft.

Second, as discussed above, in many use cases the customer may be OTN-aware and request OTN technology-specific SLOs/SLEs.

 

draft-ietf-teas-ietf-network-slices says

   IETF Network Slices are created and managed within the scope of one

   or more network technologies (e.g., IP, MPLS, optical).

 

So what CCAMP is seeking to do is clearly in scope of the concept of an IETF network slice. Any further discussion of this point would be needed in TEAS.

 

Q: Should the OTN slicing model just augment the ietf-network-slice-nbi-yang?

A: The model captured in section 4.2 of this draft targets a generic module for OTN/WDM/MW in the CCAMP WG. After the initial analysis, the authors are positive to support the augmentation approach which is already aligned with the previous comments from the mailing list.

 

That’s good to hear. I think, with that statement of intent, I’d be OK for the draft to continue with adoption and for this issue to be resolved in a later revision.

 

Q:Need a document in CCAMP to explain how OTN is used to support network slicing, a kind of applicability document (Dianele, Igor)

A: How OTN is used to support network slicing is already described in section 3 of this document. In addition, this draft describes how other OTN services are to be supported by OTN slicing, and YANG models addressing the identified gaps are also provided. 

 

Yes. I think there are three different things going on.

The first is the YANG model for augmenting the network slice service request to be specific to OTN.

The second is a YANG model for mapping the OTN slice request onto the OTN control. (A bit like the LxNM models, but also considering the existing TEAS topology models etc.)

The third is more of an applicability statement describing how an OTN is sliced and what is necessary to support a network slice.

 

I don’t much care whether these are all in the same document. They could be since there is probably not a lot of work in total, and RFCs cost money.

 

I would ask the authors to be pretty careful about the description of ACTN and to make sure they are well aligned with (including not repeating material from) draft-ietf-teas-applicability-actn-slicing.

 

Best,

Adrian