Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

From: Fatai Zhang <[email-masked]>
Date: Wed, 12 Jan 2022 02:24:11 +0000

Hi all,

All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts the polling for WG adoption.

The poll will last 2 weeks and will end on Wednesday January 26th.

Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for your reply, mandatory for the "not support" and nice to have for the "support".

Thanks,

Fatai & Daniele

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 12 Jan 2022 08:54:42 +0000

Hi Daniele, Fatai,

yes/support, I think the draft is stable enough to become WG document, and to progress in the group

Thanks
Sergio (as co-author)

From: CCAMP <[email-masked]> On Behalf Of Fatai Zhang
Sent: Wednesday, January 12, 2022 3:24 AM
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

---

From: Victor Lopez <[email-masked]>
Date: Wed, 12 Jan 2022 16:31:31 +0100

Dear all,

I support the adoption, as coauthor.

Victor

El mié, 12 ene 2022 a las 3:24, Fatai Zhang (<zhangfatai=
[email-masked]>) escribió:

> Hi all,
>
>
>
> All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03
> have been collected, this starts the polling for WG adoption.
>
>
>
> Please send email to the list indicating "yes/support" or "no/do not
> support" and a motivation for your reply, mandatory for the "not support"
> and nice to have for the "support".
>
>
>
>
>
> Thanks,
>
>
>
> Fatai & Daniele
>
>
>
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Aihua Guo <[email-masked]>
Date: Wed, 12 Jan 2022 10:32:29 -0500

Hi Fatai, All,

Yes/Support. This draft describes framework and data models to realize
technology-specific slicing with hard OTN pipes, which can be used to
support various use cases over OTN networks.

Thanks,
Aihua (as a co-author)

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 12 Jan 2022 16:17:15 +0000 (UTC)

I have some questions but support the adoption.Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Wed, Jan 12, 2022 at 3:54 AM, Belotti, Sergio (Nokia - IT/Vimercate)<[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Italo Busi <[email-masked]>
Date: Wed, 12 Jan 2022 17:07:07 +0000

Hi all,

yes/support as co-author

I think this draft is very useful to enable the delivery of new OTN-based customer services as well as the realization of network slices over OTN networks

I take the opportunity to wish you all an Happy New Year

Italo

From: Fatai Zhang [mailto:[email-masked]]
Sent: mercoledì 12 gennaio 2022 03:24
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 12 Jan 2022 19:45:50 +0000

Hi,

As co-author, yes, I support the adoption of the draft.

Best regards

Luis

De: CCAMP <[email-masked]> En nombre de Fatai Zhang
Enviado el: miércoles, 12 de enero de 2022 3:24
Para: CCAMP <[email-masked]>
Asunto: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 13 Jan 2022 14:34:33 +0000

Yes/Support (as a Co-author)

Cheers,
Reza

From: Aihua Guo <[email-masked]>
Date: Wednesday, January 12, 2022 at 10:32 AM
To: Fatai Zhang <zhangfatai=[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai, All,

Yes/Support. This draft describes framework and data models to realize technology-specific slicing with hard OTN pipes, which can be used to support various use cases over OTN networks.

Thanks,
Aihua (as a co-author)

On Tue, Jan 11, 2022 at 9:24 PM Fatai Zhang <zhangfatai=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Thanks,

Fatai & Daniele

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Zhenghaomian <[email-masked]>
Date: Thu, 13 Jan 2022 15:10:42 +0000

Yes, Support.

Best wishes,
Haomian (as a co-author)

发件人: CCAMP [mailto:[email-masked]] 代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[email-masked]>
主题: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 13 Jan 2022 17:20:16 -0000

Hi Fatai, Daniele,

I think that CCAMP should work on YANG models for slicing OTN networks. I
think that this draft forms a starting point and should be adopted, but like
Igor, "I have questions".

So, my support for adoption is heavily conditional on the authors not
believing that the approach used in the draft is fixed. (This is normal, but
it is worth highlighting in view of my thoughts, below).

I am particularly interested to look at harmonising this work with
draft-ietf-teas-applicability-actn-slicing and
<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yan
g/> draft-ietf-teas-ietf-network-slice-nbi-yang (I appreciate the work the
authors have done to synchronise with draft-ietf-teas-ietf-network-slices).
I think one question here is whether the "slice request" interface shouldn't
actually be built on
<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yan
g/> draft-ietf-teas-ietf-network-slice-nbi-yang (i.e. top down, not bottom
up as currently). The point being that "The definition of an IETF Network
Slice Service is independent of the connectivity and technologies used in
the underlay network" [draft-ietf-teas-ietf-network-slices] meaning that the
NBI in this model could be a technology-specific augmentation of
<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yan
g/> draft-ietf-teas-ietf-network-slice-nbi-yang.

Another question is why there is the need to introduce the complexity of
interfaces and controllers shown in Figure 2, when Figure 1 of
draft-ietf-teas-applicability-actn-slicing considers a more simple mapping
between the slicing and ACTN architectures. That is, why does the CMI appear
as different from the OTN-SC NBI and the NSC NBI?

We might also debate the meaning of "E2E Slice Controller" since this term
is not mentioned anywhere except in Figure 2 and only appears once in
draft-ietf-teas-ietf-network-slices (in Figure 2) that appears to have
escaped being cleaned up.

But, I think these are questions that can be easily resolved in discussions
within the WG, so adoption should be safe.

Best,

Adrian

PS. At some stage the AD is going to ask, "Please find a way to reduce the
front page authors to 5 or fewer." Experience suggests that it is easier to
do this sooner rather than later, and it is better if the authors resolve
that rather than requiring the chairs to force the point.

From: CCAMP <[email-masked]> On Behalf Of Fatai Zhang
Sent: 12 January 2022 02:24
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

 

Thanks,

Fatai & Daniele

---

From: Henry Yu <[email-masked]>
Date: Thu, 13 Jan 2022 12:35:52 -0500

Yes/Support.

Thanks,

Henry (as a co-author)

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 14 Jan 2022 07:00:00 +0000

Hi Adrian,

I also like Igor style, “I have questions”, even though Igor’s questions are virtual/invisible, :)

I would like to leave the authors to clarify your questions.

Thanks
Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2022年1月14日 1:20
收件人: 'Fatai Zhang' <zhangfatai=[email-masked]>; 'CCAMP' <[email-masked]>
主题: Re: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai, Daniele,

I think that CCAMP should work on YANG models for slicing OTN networks. I think that this draft forms a starting point and should be adopted, but like Igor, “I have questions”.

So, my support for adoption is heavily conditional on the authors not believing that the approach used in the draft is fixed. (This is normal, but it is worth highlighting in view of my thoughts, below).

I am particularly interested to look at harmonising this work with draft-ietf-teas-applicability-actn-slicing and draft-ietf-teas-ietf-network-slice-nbi-yang<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/> (I appreciate the work the authors have done to synchronise with draft-ietf-teas-ietf-network-slices). I think one question here is whether the “slice request” interface shouldn’t actually be built on draft-ietf-teas-ietf-network-slice-nbi-yang<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/> (i.e. top down, not bottom up as currently). The point being that “The definition of an IETF Network Slice Service is independent of the connectivity and technologies used in the underlay network” [draft-ietf-teas-ietf-network-slices] meaning that the NBI in this model could be a technology-specific augmentation of draft-ietf-teas-ietf-network-slice-nbi-yang<https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>.
Another question is why there is the need to introduce the complexity of interfaces and controllers shown in Figure 2, when Figure 1 of draft-ietf-teas-applicability-actn-slicing considers a more simple mapping between the slicing and ACTN architectures. That is, why does the CMI appear as different from the OTN-SC NBI and the NSC NBI?
We might also debate the meaning of “E2E Slice Controller” since this term is not mentioned anywhere except in Figure 2 and only appears once in draft-ietf-teas-ietf-network-slices (in Figure 2) that appears to have escaped being cleaned up.

But, I think these are questions that can be easily resolved in discussions within the WG, so adoption should be safe.

Best,
Adrian

PS. At some stage the AD is going to ask, “Please find a way to reduce the front page authors to 5 or fewer.” Experience suggests that it is easier to do this sooner rather than later, and it is better if the authors resolve that rather than requiring the chairs to force the point.

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Fatai Zhang
Sent: 12 January 2022 02:24
To: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 14 Jan 2022 08:34:23 +0000 (UTC)

Hi Fatai,
I like that you and Adrian like my style, but I did ask questions before the last IETF. The basic one is this:When I explain my wife what IETF network slice is, I say: Remember, we have this thing called IP VPN?  Network slice is roughly IP VPN with QOS parameters. 
Considering that L1VPN cannot be without QOS, my question to the authors what is the difference between L1VPN and OTN slice?
Cheers,Igor

  On Fri, Jan 14, 2022 at 2:00 AM, Fatai Zhang<zhangfatai=[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 14 Jan 2022 16:14:26 +0000

Indeed a very good question…which is similar to the more generic question of what is the difference between a LxVPN with QoS (e.g a L3VPN bound to a TE tunnel) and a slice which I tried to ask in TEAS (but that’s a different story).
Let’s focus on the difference between L1VPN and OTN slice here.

BR
Daniele

From: CCAMP <[email-masked]> On Behalf Of Igor Bryskin
Sent: den 14 januari 2022 09:34
To: zhangfatai=[email-masked]; Fatai Zhang <zhangfatai=[email-masked]>; [email-masked]; 'Fatai Zhang' <zhangfatai=[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai,

I like that you and Adrian like my style, but I did ask questions before the last IETF. The basic one is this:
When I explain my wife what IETF network slice is, I say: Remember, we have this thing called IP VPN?  Network slice is roughly IP VPN with QOS parameters.

Cheers,
Igor
Sent from Yahoo Mail on Android<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b3081161b9d5ba0&q=1&e=df107fd9-1747-4e23-801b-18984b9b6289&u=https%3A%2F%2Fgo.onelink.me%2F107872968%3Fpid%3DInProduct%26c%3DGlobal_Internal_YGrowth_AndroidEmailSig__AndroidUsers%26af_wl%3Dym%26af_sub1%3DInternal%26af_sub2%3DGlobal_YGrowth%26af_sub3%3DEmailSignature>

On Fri, Jan 14, 2022 at 2:00 AM, Fatai Zhang
<zhangfatai=[email-masked]<mailto:zhangfatai=[email-masked]>> wrote:
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Jan 2022 16:56:54 -0000

I think there is a difference between a L3/L2 VPN and a L1VPN that is to do with the nature of connectivity in the underlying network. A packet VPN is expressed as a set of edge points and the edge connectivity capacities, but not the edge-to-edge capacities. A L1VPN (at least for some L1 technologies – but not all?) has to be expressed in terms of edge-to-edge capacities because you cannot do “on-demand” traffic routing within the network – the flow markings are at a macro level.

>From that perspective, I’d agree that L1VPN is close to L1 slicing. It would be good to hear the authors spell out the differences that they obviously have in mind.

But, not only did Daniele ask his question in TEAS, he also go an answer 😊. There are service models in which a network slice may look like a “VPN with QoS” – those are the enhanced VPN cases. But there are also service models where the edge-to-edge flows are spelled out in more detail than in a VPN.

Ciao,

Adrian

From: Daniele Ceccarelli <[email-masked]> 
Sent: 14 January 2022 16:14
To: Igor Bryskin <[email-masked]>; zhangfatai=[email-masked]; [email-masked]; 'CCAMP' <[email-masked]>
Subject: RE: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

BR
Daniele 

From: CCAMP <[email-masked] <mailto:[email-masked]> > On Behalf Of Igor Bryskin
Sent: den 14 januari 2022 09:34
To: zhangfatai=[email-masked] <mailto:zhangfatai=[email-masked]> ; Fatai Zhang <zhangfatai=[email-masked] <mailto:zhangfatai=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'Fatai Zhang' <zhangfatai=[email-masked] <mailto:zhangfatai=[email-masked]> >; 'CCAMP' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai,

Cheers,

Igor

Sent from Yahoo Mail on Android <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b3081161b9d5ba0&q=1&e=df107fd9-1747-4e23-801b-18984b9b6289&u=https%3A%2F%2Fgo.onelink.me%2F107872968%3Fpid%3DInProduct%26c%3DGlobal_Internal_YGrowth_AndroidEmailSig__AndroidUsers%26af_wl%3Dym%26af_sub1%3DInternal%26af_sub2%3DGlobal_YGrowth%26af_sub3%3DEmailSignature> 

<zhangfatai=[email-masked]> wrote:

_______________________________________________
CCAMP mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Aihua Guo <[email-masked]>
Date: Fri, 14 Jan 2022 17:19:51 -0500

Hi Adrian, Daniele and Igor,

IMHO an OTN slice, like an IETF network slice, is used to represent an
intent from a (internal or external) customer's view. This intent includes
a combination of resource requirements which can be expressed by
connectivities or topologies, along with the common and OTN
technology-specific SLOs. Customers usually do not care how an OTN slice is
realized at the control plane and/or data plane, and VPN is one of the
possible realizations.

To summarize, an L1VPN with QoS parameters can be considered as a possible
realization of an OTN slice.

Also, if I understand it correctly, L1VPN is implemented using the control
plane per rfc4878 and is not targeted as an NBI model.

Thanks,
Aihua

On Fri, Jan 14, 2022 at 11:57 AM Adrian Farrel <[email-masked]> wrote:

> I think there is a difference between a L3/L2 VPN and a L1VPN that is to
> do with the nature of connectivity in the underlying network. A packet VPN
> is expressed as a set of edge points and the edge connectivity capacities,
> but not the edge-to-edge capacities. A L1VPN (at least for some L1
> technologies – but not all?) has to be expressed in terms of edge-to-edge
> capacities because you cannot do “on-demand” traffic routing within the
> network – the flow markings are at a macro level.
>
>
>
> From that perspective, I’d agree that L1VPN is close to L1 slicing. It
> would be good to hear the authors spell out the differences that they
> obviously have in mind.
>
>
>
> But, not only did Daniele ask his question in TEAS, he also go an answer
> 😊. There are service models in which a network slice may look like a
> “VPN with QoS” – those are the enhanced VPN cases. But there are also
> service models where the edge-to-edge flows are spelled out in more detail
> than in a VPN.
>
>
>
> Ciao,
>
> Adrian
>
>
>
> *From:* Daniele Ceccarelli <[email-masked]>
> *Sent:* 14 January 2022 16:14
> *To:* Igor Bryskin <[email-masked]>; zhangfatai=
> [email-masked]; [email-masked]; 'CCAMP' <[email-masked]>
> *Subject:* RE: [CCAMP] 答复: WG adoption poll on
> draft-zheng-ccamp-yang-otn-slicing-03
>
>
>
> Indeed a very good question…which is similar to the more generic question
> of what is the difference between a LxVPN with QoS (e.g a L3VPN bound to a
> TE tunnel) and a slice which I tried to ask in TEAS (but that’s a different
> story).
>
> *From:* CCAMP <[email-masked]> *On Behalf Of *Igor Bryskin
> *Sent:* den 14 januari 2022 09:34
> *To:* zhangfatai=[email-masked]; Fatai Zhang <
> zhangfatai=[email-masked]>; [email-masked]; 'Fatai
> Zhang' <zhangfatai=[email-masked]>; 'CCAMP' <[email-masked]>
> *Subject:* Re: [CCAMP] 答复: WG adoption poll on
> draft-zheng-ccamp-yang-otn-slicing-03
>
>
>
> Hi Fatai,
>
>
>
> When I explain my wife what IETF network slice is, I say: Remember, we
> have this thing called IP VPN?  Network slice is roughly IP VPN with QOS
> parameters.
>
>
>
> Considering that L1VPN cannot be without QOS, my question to the authors
> what is the difference between L1VPN and OTN slice?
>
>
>
> Cheers,
>
> Igor
>
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b3081161b9d5ba0&q=1&e=df107fd9-1747-4e23-801b-18984b9b6289&u=https%3A%2F%2Fgo.onelink.me%2F107872968%3Fpid%3DInProduct%26c%3DGlobal_Internal_YGrowth_AndroidEmailSig__AndroidUsers%26af_wl%3Dym%26af_sub1%3DInternal%26af_sub2%3DGlobal_YGrowth%26af_sub3%3DEmailSignature>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Jan 2022 15:03:57 -0500

I support WG Adoption.

I did have some questions and thankfully Aihua has answered mine as well.

Regards

Gyan

On Fri, Jan 14, 2022 at 5:20 PM Aihua Guo <[email-masked]> wrote:

>> [email-masked]; [email-masked]; 'CCAMP' <[email-masked]
>> >
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Dieter Beller <[email-masked]>
Date: Sun, 16 Jan 2022 14:19:48 +0100

Hi Daniele and Fatai,

yes/support as co-author.

Thanks,
Dieter

On 12.01.2022 03:24, Fatai Zhang wrote:
>
> Hi all,
>
> All the IPR declarations regarding 
> draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts 
> the polling for WG adoption.
>
> support" and a motivation for your reply, mandatory for the "not 
> support" and nice to have for the "support".
>
> Thanks,
>
> Fatai & Daniele
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 16 Jan 2022 16:22:56 +0000 (UTC)

Hi Gyan and All,
I think one problem with OTN slices is the term itself.  After all, unlike IP OTN is already sliced (in time slots) with very sharp and fine knife, so much so that any such a slice no matter how big or small has no influence on any other slice, right? Than what more slicing one needs?If anything, the NBI suggests something directly opposite to slicing - grouping natural OTN slices into bigger chunks for all the reasons the authors find useful, for example, to adequately support IP slicing ( it is another good question whether  to do this is any better than using the natural OTN slices in a statistically shared manner).
Cheers,Igor

  On Sat, Jan 15, 2022 at 3:04 PM, Gyan Mishra<[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 17 Jan 2022 10:54:14 +0000

Hi Aihua,

The distinction between realization and intention makes sense. I believe that from the realization point of view they are identical (control plane excluded) but from an intent point of view there is a difference.

Cheers,
Daniele

From: Aihua Guo <[email-masked]>
Sent: den 14 januari 2022 23:20
To: [email-masked]
Cc: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; Fatai Zhang <zhangfatai=[email-masked]>; CCAMP <[email-masked]>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

IMHO an OTN slice, like an IETF network slice, is used to represent an intent from a (internal or external) customer's view. This intent includes a combination of resource requirements which can be expressed by connectivities or topologies, along with the common and OTN technology-specific SLOs. Customers usually do not care how an OTN slice is realized at the control plane and/or data plane, and VPN is one of the possible realizations.

To summarize, an L1VPN with QoS parameters can be considered as a possible realization of an OTN slice.

Also, if I understand it correctly, L1VPN is implemented using the control plane per rfc4878 and is not targeted as an NBI model.

Thanks,
Aihua

On Fri, Jan 14, 2022 at 11:57 AM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
I think there is a difference between a L3/L2 VPN and a L1VPN that is to do with the nature of connectivity in the underlying network. A packet VPN is expressed as a set of edge points and the edge connectivity capacities, but not the edge-to-edge capacities. A L1VPN (at least for some L1 technologies – but not all?) has to be expressed in terms of edge-to-edge capacities because you cannot do “on-demand” traffic routing within the network – the flow markings are at a macro level.

Ciao,
Adrian

From: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Sent: 14 January 2022 16:14
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; zhangfatai=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

BR
Daniele

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Igor Bryskin
Sent: den 14 januari 2022 09:34
To: zhangfatai=[email-masked]<mailto:zhangfatai=[email-masked]>; Fatai Zhang <zhangfatai=[email-masked]<mailto:zhangfatai=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Fatai Zhang' <zhangfatai=[email-masked]<mailto:zhangfatai=[email-masked]>>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Mon, 17 Jan 2022 16:56:20 +0000

This is also my understanding.

Igor is right that from a data plane perspective all the “ingredients” to realize an OTN slice are defined.

Section 3 of the draft describes the framework for OTN slicing and identifies few gaps in the YANG data models. No gaps are identified in the data plane.

Section 4 of the draft proposes new YANG data models to address the gaps identified in section 3.

Italo

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: lunedì 17 gennaio 2022 11:54
To: Aihua Guo <[email-masked]>; [email-masked]
Cc: Igor Bryskin <[email-masked]>; Fatai Zhang <zhangfatai=[email-masked]>; CCAMP <[email-masked]>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Aihua,

Cheers,
Daniele

From: Aihua Guo <[email-masked]<mailto:[email-masked]>>
Sent: den 14 januari 2022 23:20
To: [email-masked]<mailto:[email-masked]>
Cc: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Fatai Zhang <zhangfatai=[email-masked]<mailto:zhangfatai=[email-masked]>>; CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Thanks,
Aihua

Ciao,
Adrian

BR
Daniele

Hi Fatai,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 17 Jan 2022 17:24:59 +0000 (UTC)

Hi Adrian, 
Thanks for your inside.
Firstly, I still can't see a daylight between L1VPN and OTN slice. I'd also like to hear from the authors something more than L1VPN is one way to implement OTN slice. What would be other ways? And what about  L0? Would we also need Och slicing, microwave slicing, etc.? I think such a discussion would be welcome addition to the draft.
Secondly, we put a lot of effort into L1VPNs - we had a dedicated WG, which successfully fulfilled its charter and was closed with honors. Looking back though, I hope you'd agree that the level of L1VPN success/deployments, to put it mildly, has not been as high, as we had hoped it would be.  In your opinion why is that? Could it be that because over the years folks realized it is far simpler and straightforward (yet sufficient) to plan and use OTN resources in a shared manner, providing simple p2p connectivity services, rather than breaking the resources into VPNs and providing more complex L1VPN services?
Finally, I have a hypothetical question for you. Imagine that the IP layer data plane was naturally sliced as OTN data plane. For example, imgine IP layer where the only way to achieve any connectivity is via RSVP TE controlled LSPs, which have impenetrable walls separating them from each other (regardless whether you want such walls or not). Do you think we would be working on slicing in such IP?
Thanks,Igor

  On Mon, Jan 17, 2022 at 5:54 AM, Daniele Ceccarelli<[email-masked]> wrote:   <!--#yiv4373471841 filtered {}#yiv4373471841 filtered {}#yiv4373471841 filtered {}#yiv4373471841 filtered {}#yiv4373471841 filtered {}#yiv4373471841 filtered {}#yiv4373471841 p.yiv4373471841MsoNormal, #yiv4373471841 li.yiv4373471841MsoNormal, #yiv4373471841 div.yiv4373471841MsoNormal {margin:0cm;font-size:12.0pt;font-family:"Times New Roman", serif;}#yiv4373471841 a:link, #yiv4373471841 span.yiv4373471841MsoHyperlink {color:blue;text-decoration:underline;}#yiv4373471841 span.yiv4373471841EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv4373471841 .yiv4373471841MsoChpDefault {font-family:"Calibri", sans-serif;}#yiv4373471841 filtered {}#yiv4373471841 div.yiv4373471841WordSection1 {}-->
Hi Aihua,

 
Cheers,
Daniele  

 

 

 
Thanks,
 
Aihua

 
>From that perspective, I’d agree that L1VPN is close to L1 slicing. It would be good to hear the authors spell out the differences that they obviously have in mind.

But, not only did Daniele ask his question in TEAS, he also go an answer😊. There are service models in which a network slice may look like a “VPN with QoS” – those are the enhanced VPN cases. But there are also service models where the edge-to-edge flows are spelled out in more detail than in a VPN.

Ciao,
 
Adrian

From: Daniele Ceccarelli <[email-masked]>
Sent: 14 January 2022 16:14
To: Igor Bryskin <[email-masked]>; zhangfatai=[email-masked];[email-masked]; 'CCAMP' <[email-masked]>
Subject: RE: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

 

BR
Daniele 

From: CCAMP <[email-masked]>On Behalf Of Igor Bryskin
Sent: den 14 januari 2022 09:34
To: zhangfatai=[email-masked]; Fatai Zhang <zhangfatai=[email-masked]>;[email-masked]; 'Fatai Zhang' <zhangfatai=[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] 答复: WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai,

 

 
Cheers,
 
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 17 Jan 2022 17:35:43 +0000 (UTC)

Sorry, I thanked Adrian for his insight, not inside ;)

  On Mon, Jan 17, 2022 at 12:25 PM, Igor Bryskin<i_bryskin=[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 17 Jan 2022 14:40:15 -0500

yes/support.

Thanks,
- Xufeng

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Jan 2022 03:25:45 -0500

Hi Adrian

I agree with all your comments related to this draft especially the
complexity with this approach as compared to ACTN architecture.  One
critical  point you make is that the slice service should be independent of
underlay technology.  As OTN is a component of the underlay it goes against
the agnostic slice approach taken with IETF Network Slice.

Others have mentioned the same related to underlay technology slice added
complexity and does that mean a different  slice Yang model for each L1
Technology “Bottoms Up” approach. 😁

Comments in-line

Kind Regards

Gyan

On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel <[email-masked]> wrote:

> think that this draft forms a starting point and should be adopted, but
> like Igor, “I have questions”.
>
>  Gyan>  I support WG adoption and I think all the comments mentioned can
> be addressed.
>
> believing that the approach used in the draft is fixed. (This is normal,
> but it is worth highlighting in view of my thoughts, below).
>
>
>
> draft-ietf-teas-ietf-network-slice-nbi-yang
> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
> (I appreciate the work the authors have done to synchronise with
> draft-ietf-teas-ietf-network-slices).
>
     Gyan> Agreed

I think one question here is whether the “slice request” interface
> shouldn’t actually be built on draft-ietf-teas-ietf-network-slice-nbi-yang
> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
> (i.e. top down, not bottom up as currently).
>
    Gyan> Agreed.

The point being that “The definition of an IETF Network Slice Service is
> independent of the connectivity and technologies used in the underlay
> network” [draft-ietf-teas-ietf-network-slices] meaning that the NBI in this
> model could be a technology-specific augmentation of
> draft-ietf-teas-ietf-network-slice-nbi-yang
> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
> .
>
>     Gyan> Agreed

> interfaces and controllers shown in Figure 2, when Figure 1 of draft-ietf-teas-applicability-actn-slicing
> considers a more simple mapping between the slicing and ACTN architectures.
> That is, why does the CMI appear as different from the OTN-SC NBI and the
> NSC NBI?
>
   Gyan> Completely Agree.  ACTN mapping is a much simpler mapping.

> We might also debate the meaning of “E2E Slice Controller” since this term
> is not mentioned anywhere except in Figure 2 and only appears once in draft-ietf-teas-ietf-network-slices
> (in Figure 2) that appears to have escaped being cleaned up.
>
>
>
> But, I think these are questions that can be easily resolved in
> discussions within the WG, so adoption should be safe.
>
>  Gyan> Agreed
>
> Best,
>
> Adrian
>
>
>
> PS. At some stage the AD is going to ask, “Please find a way to reduce the
> front page authors to 5 or fewer.” Experience suggests that it is easier to
> *From:* CCAMP <[email-masked]> *On Behalf Of *Fatai Zhang
>
>
> *Sent:* 12 January 2022 02:24
> *To:* CCAMP <[email-masked]>
> *Subject:* [CCAMP] WG adoption poll on
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 21 Jan 2022 15:55:59 +0000 (UTC)

Adrian,,  Daniele, Fatai, Aivua and All,
OTN will certainly have a role in network slicing, and I like the idea of having a CCAMP document to this end.This said I have a big issue with the terms "OTN slice" and "OTN slicing".I've raised a few questions. Some of them are not answered yet. Some of them I think need to be answered in broader NS framework context (Adrian's "what's what" discussions ;) )

Let's focus on the following four for now:
- What is the difference between OTN slice and L1VPN?- What is the difference between OTN slice and OTN abstract topology?- How deep into transport layers we have/should/need to go with the network slicing?-  In case of OTN slicing where connectivity types, such as p2mp, mp2p and mp2mp, will come from?

1. We started with: What is the difference between OTN slice and L1VPN? So far I heard: L1VPN is one way to realize OTN slice. Ok, what are other ways? To me OTN slice still looks exactly like L1VPN controlled (as everything else today) via YANG based NBI, rather than SNMP as it used to. What am I missing?
2. More importantly, what is the difference between OTN slice and OTN abstract topology?
In this case the authors seem to see no difference between the two. They use the terms interchangeably and, if one substitutes word "slice" with word "topology" and word "SLO" with "configured link/CM entry attribute", one might very well get verbatim abstracts from ACTN documents. I believe they are confusing slicing with basic resource allocation and abstract topology related operations (thoroughly discussed several years ago in the ACTN context). I don't blame them, the differences are subtle, and AFAIK have not been discussed yet. What is especially confusing is that both Abstract Topology service and Network Slice service may refer to the same abstract topology, but for different purposes and with different benefits for the client.
I could be wrong here, but after all the discussions we have had in the context of NS, I've come to see a big difference between the Abstract Topology service and NS service. The main role of the former is to allocate resources for and convey to the client characteristics of a logical network (either configured by the client or internally generated by the server) as snapshots in time - at the time of the topology presentation following with notifications about changes. This allows for the client to make proper TE decisions, like accurate path computation.
I think NS service includes Abstract Topology service but goes way beyond that. One important role of the NS service is to *sustain* logical network characters (SLIs) over the service lifetime constantly bending them towards committed SLOs under conditions of some adversity, such as congestion, misbehavior of other slices, etc. This allows for the client to utilize logical network as a stable, reliable, predictable and independent physical network. Importantly, while this role is imperative and challenging in a messy layer network with shared continuous media (like IP), in the well organized  OTN l, where network resources are split neatly and naturally into tokens/units inherently independent from each other, said NS service role amounts to very little (if anything at all). 

Another important role of NS service is to provide various connectivity constructs, some of which - p2mp, mp2p, etc.-  cannot be modeled as topological elements. Again, while meaningful in IP, in OTN with its connection-oriented connectivity effectively limited to p2p, this NS service role also amounts to nothing. Therefore, I believe that, while Abstract Topology service is useful in all layers, NS service could be limited to packet switching layers, and the usual pattern -here is layer independent stuff and here are layer specific augmentations- should be broken for NS.
3. How deep we have to go with network slicing?
We all understand and agree that NS is needed in IP (and for very good reasons). But should/could we stop at IP or should we slice into transport layers? If the latter, why stop at OTN? Perhaps we should slice OCh and other layers all the way to the fibers (and surely find a way to slice fibers as well;))? And what about networks without OTN layer? with the network slicing will be different on such networks?My answer: not only we need to build network slicing top to bottom (as Adrian and Gyan say), we should stop slicing at IP (for the reasons described above in 2) and have lower layers support the IP slices ideally in exactly same way as all their other clients, that is, doing nothing specific for IP slices. Surely, this would keep inter-layer relationships much simple.
4. Where p2mp, mp2p, mp2mp connectivity will come from?
NS framework requires various connectivity types to be provided/supported by NS service. Some of them for all practical purposes could be achieved only in Ia connectionless packet-switching layer, such as IP (its inherent connectionless nature gives rise to most efficient realization of such connectivity types). This IMHO is another reason why we should limit network slicing to IP layer. Otherwise, where the complex connectivity types will come from?

My conclusion is this. Network slicing could and should be limited to IP layer. The underlying transport should support IP slices, but not perform slicing itself. The tools available to transport layers - topology, tunnel, path computation, VN, etc. models/NBIs should be sufficient for this purpose. A document describing this would be useful.
Cheers,Igor

    On Friday, January 21, 2022, 03:26:15 AM EST, Gyan Mishra <[email-masked]> wrote:  

Hi Adrian 
I agree with all your comments related to this draft especially the complexity with this approach as compared to ACTN architecture.  One critical  point you make is that the slice service should be independent of underlay technology.  As OTN is a component of the underlay it goes against the agnostic slice approach taken with IETF Network Slice.  
Others have mentioned the same related to underlay technology slice added complexity and does that mean a different  slice Yang model for each L1 Technology “Bottoms Up” approach. 😁
Comments in-line 
Kind Regards
Gyan
On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel <[email-masked]> wrote:

Hi Fatai, Daniele,

 Gyan>  I support WG adoption and I think all the comments mentioned can be addressed.

I am particularly interested to look at harmonising this work with draft-ietf-teas-applicability-actn-slicing and draft-ietf-teas-ietf-network-slice-nbi-yang (I appreciate the work the authors have done to synchronise with draft-ietf-teas-ietf-network-slices). 

     Gyan> Agreed

I think one question here is whether the “slice request” interface shouldn’t actually be built on draft-ietf-teas-ietf-network-slice-nbi-yang (i.e. top down, not bottom up as currently). 

    Gyan> Agreed.  

The point being that “The definition of an IETF Network Slice Service is independent of the connectivity and technologies used in the underlay network” [draft-ietf-teas-ietf-network-slices] meaning that the NBI in this model could be a technology-specific augmentation of draft-ietf-teas-ietf-network-slice-nbi-yang.

    Gyan> Agreed 

 Gyan> Agreed 

Best,

Adrian

Hi all,

 

Thanks,

Fatai & Daniele

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Aihua Guo <[email-masked]>
Date: Fri, 21 Jan 2022 14:07:33 -0500

Hi Gyan,

I'd agree with you and Adrian that a technology-agnostic network slicing,
i.e. IETF NS can be used to specify slice requests regardless of underlay
network technologies - whether it being IP or OTN. Actually, in
draft-zheng-ccamp-yang-otn-slicing, Figure 2 describes the support for this
scenario with multiple options, as shown below:

                         +--------------------+

                         | Provider's User    |

                         +--------|-----------+

                                  | CMI

          +-----------------------+----------------------------+

          |          Orchestrator / E2E Slice Controller       |

          +------------+-----------------------------+---------+

                       |                             | NSC-NBI

                       |       +---------------------+---------+

                       |       | IETF Network Slice Controller |

                       |       +-----+---------------+---------+

                       |*option3*      |*option 2*       |

                       | OTN-SC NBI  |OTN-SC NBI     |

          +------------+-------------+--------+      | *option 1*

          |               OTN-SC              |      |

          +--------------------------+--------+      |

                                     | MPI           | MPI

          +--------------------------+---------------+---------+

          |                         PNC                        |

          +--------------------------+-------------------------+

                                     | SBI

                         +-----------+----------+

                         |OTN Physical Network  |

                         +----------------------+

*Option 1:* the IETF NSC receives a technology-agnostic slice request, it
uses MPI to realize the slice on PNC using available mechanisms, such as
L1VPN, abstract TE topologies, TE tunnels, or any proprietary technologies
the controller chooses to use. In this case, the OTN-SC NBI is not used.

*Option 2:* the IETF NSC receives a technology-agnostic slice request and
delegates the request to the OTN-SC by using the OTN slicing interface at
the OTN-SC NBI. The OTN-SC NBI is technology specific and augments the IETF
NSC NBI. Therefore, the IETF NSC request to OTN-SC can be either technology
agnostic or OTN specific depending on the realization of IETF NSC. The
OTN-SC will in turn work with the PNC and realize the slice. In this
option, OTN-SC is essentially a subordinate slice controller of the IETF
NSC which also meets the hierarchical nature of slice control as described
in the network slice framework document.

Both Option 1 and Option 2 are in line with the view that a customer can
request a technology-agnostic NS and the IETF-NSC can realize the slice in
its underlay networks whether it being OTN or packet.

Additionally, *Option 3: * a customer who is OTN-aware may use the
augmented OTN-SC NBI to request an OTN slice with OTN-specific SLOs (e.g.
BER, bandwidth in terms of the # of time slots), and the OTN SC realizes
the slice by working with the underlying PNC(s) in single- or multi-domain
network scenarios. Several use cases for option 3 are also described in the
draft.

To summarize, the OTN slicing model provides a service-intent interface
that supports the configuration of OTN slices, which can be realized by the
OTN-SC controller in various ways. The OTN SC also allows an OTN-aware
customer to create OTN slices with OTN-specific SLOs.

I hope the above clarification could be helpful. Authors are open to make
further clarifications in the document to align with the framework of IETF
network slicing.

Thanks,

Aihua

On Fri, Jan 21, 2022 at 3:26 AM Gyan Mishra <[email-masked]> wrote:

>> shouldn’t actually be built on
>> We might also debate the meaning of “E2E Slice Controller” since this
>> term is not mentioned anywhere except in Figure 2 and only appears once in draft-ietf-teas-ietf-network-slices
>> PS. At some stage the AD is going to ask, “Please find a way to reduce
>> the front page authors to 5 or fewer.” Experience suggests that it is
>> easier to do this sooner rather than later, and it is better if the authors
>> resolve that rather than requiring the chairs to force the point.
>>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Jan 2022 14:59:33 -0500

Under what circumstance, even if the customer knows (out of band) that 
the operator has OTN capability) would the customer somehow specify OTN 
specifics as part of requesting an end-to-end network slice (which 
inherently has to traverse more than the OTN?)

Yours,
Joel

On 1/21/2022 2:07 PM, Aihua Guo wrote:
> Hi Gyan,
> 
> I'd agree with you and Adrian that a technology-agnostic network 
> slicing, i.e. IETF NS can be used to specify slice requests regardless 
> of underlay network technologies - whether it being IP or OTN. Actually, 
> in draft-zheng-ccamp-yang-otn-slicing, Figure 2 describes the support 
> for this scenario with multiple options, as shown below:
> 
>                           +--------------------+____
> 
>                           | Provider's User    |____
> 
>                           +--------|-----------+____
> 
>                                    | CMI____
> 
>            +-----------------------+----------------------------+____
> 
>            |          Orchestrator / E2E Slice Controller       |____
> 
>            +------------+-----------------------------+---------+____
> 
>                         |                             | NSC-NBI____
> 
>                         |       +---------------------+---------+____
> 
>                         |       | IETF Network Slice Controller |____
> 
>                         |       +-----+---------------+---------+____
> 
>                         |/_option3_/      |/_option 2_/       |____
> 
>                         | OTN-SC NBI  |OTN-SC NBI     |____
> 
>            +------------+-------------+--------+      | /_option 1_/____
> 
>            |               OTN-SC              |      |____
> 
>            +--------------------------+--------+      |____
> 
>                                       | MPI           | MPI____
> 
>            +--------------------------+---------------+---------+____
> 
>            |                         PNC                        |____
> 
>            +--------------------------+-------------------------+____
> 
>                                       | SBI____
> 
>                           +-----------+----------+____
> 
>                           |OTN Physical Network  |____
> 
>                           +----------------------+____
> 
> __ __
> 
> */_Option 1:_/* the IETF NSC receives a technology-agnostic slice 
> request, it uses MPI to realize the slice on PNC using available 
> mechanisms, such as L1VPN, abstract TE topologies, TE tunnels, or any 
> proprietary technologies the controller chooses to use. In this case, 
> the OTN-SC NBI is not used.__
> 
> __ __
> 
> */_Option 2:_/* the IETF NSC receives a technology-agnostic slice 
> request and delegates the request to the OTN-SC by using the OTN slicing 
> interface at the OTN-SC NBI. The OTN-SC NBI is technology specific and 
> augments the IETF NSC NBI. Therefore, the IETF NSC request to OTN-SC can 
> be either technology agnostic or OTN specific depending on the 
> realization of IETF NSC. The OTN-SC will in turn work with the PNC and 
> realize the slice. In this option, OTN-SC is essentially a subordinate 
> slice controller of the IETF NSC which also meets the hierarchical 
> nature of slice control as described in the network slice framework 
> document.
> 
> __
> 
> __ __
> 
> request a technology-agnostic NS and the IETF-NSC can realize the slice 
> in its underlay networks whether it being OTN or packet.____
> 
> 
> Additionally, */_Option 3: _/* a customer who is OTN-aware may use the 
> augmented OTN-SC NBI to request an OTN slice with OTN-specific SLOs 
> (e.g. BER, bandwidth in terms of the # of time slots), and the OTN SC 
> realizes the slice by working with the underlying PNC(s) in single- or 
> multi-domain network scenarios. Several use cases for option 3 are also 
> described in the draft.
> 
> 
> that supports the configuration of OTN slices, which can be realized by 
> the OTN-SC controller in various ways. The OTN SC also allows an 
> OTN-aware customer to create OTN slices with OTN-specific SLOs.
> 
> __ __
> 
> I hope the above clarification could be helpful. Authors are open to 
> make further clarifications in the document to align with the framework 
> of IETF network slicing.__
> 
> __ __
> 
> Thanks,____
> 
> Aihua
> 
> 
> On Fri, Jan 21, 2022 at 3:26 AM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Hi Adrian
> 
>     critical  point you make is that the slice service should be
>     independent of underlay technology.  As OTN is a component of the
>     underlay it goes against the agnostic slice approach taken with IETF
>     Network Slice.
> 
>     Others have mentioned the same related to underlay technology slice
>     added complexity and does that mean a different  slice Yang model
>     for each L1 Technology “Bottoms Up” approach. 😁
> 
>     Comments in-line
> 
>     Kind Regards
> 
>     Gyan
> 
>     On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Fatai, Daniele,____
> 
>         __ __
> 
>         I think that CCAMP should work on YANG models for slicing OTN
>         networks. I think that this draft forms a starting point and
>         should be adopted, but like Igor, “I have questions”.____
> 
>         __ Gyan>  I support WG adoption and I think all the comments
>         mentioned can be addressed.__
> 
>         So, my support for adoption is heavily conditional on the
>         authors not believing that the approach used in the draft is
>         fixed. (This is normal, but it is worth highlighting in view of
>         my thoughts, below).____
> 
>         __
> 
>         I am particularly interested to look at harmonising this work
>         with draft-ietf-teas-applicability-actn-slicing and
>         I think one question here is whether the “slice request”
>         interface shouldn’t actually be built on
>         The point being that “The definition of an IETF Network Slice
>         Service is independent of the connectivity and technologies used
>         in the underlay network” [draft-ietf-teas-ietf-network-slices]
>         meaning that the NBI in this model could be a
>         technology-specific augmentation of
>         <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>.____
> 
>          Gyan> Agreed
> 
>         Another question is why there is the need to introduce the
>         complexity of interfaces and controllers shown in Figure 2, when
>         Figure 1 of draft-ietf-teas-applicability-actn-slicing considers
>         a more simple mapping between the slicing and ACTN
>         architectures. That is, why does the CMI appear as different
>         from the OTN-SC NBI and the NSC NBI?
> 
>         ____
>         We might also debate the meaning of “E2E Slice Controller” since
>         this term is not mentioned anywhere except in Figure 2 and only
>         appears once in draft-ietf-teas-ietf-network-slices (in Figure
>         2) that appears to have escaped being cleaned up.____
> 
>         __ __
> 
>         discussions within the WG, so adoption should be safe.____
> 
>         __ Gyan> Agreed __
> 
>         Best,____
> 
>         Adrian____
> 
>         __ __
> 
>         PS. At some stage the AD is going to ask, “Please find a way to
>         reduce the front page authors to 5 or fewer.” Experience
>         suggests that it is easier to do this sooner rather than later,
>         and it is better if the authors resolve that rather than
>         requiring the chairs to force the point.____
> 
>         __ __
> 
>         *From:*CCAMP <[email-masked]
>         <mailto:[email-masked]>> *On Behalf Of *Fatai Zhang
> 
> 
>         *To:* CCAMP <[email-masked] <mailto:[email-masked]>>
>         draft-zheng-ccamp-yang-otn-slicing-03____
> 
>         __ __
> 
>         Hi all,____
> 
>         __ __
> 
>         draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this
>         starts the polling for WG adoption.____
> 
>         __ __
> 
>         The poll will last 2 weeks and will end on Wednesday January
>         26th.____
> 
>         __ __
> 
>         Please send email to the list indicating "yes/support" or "no/do
>         not support" and a motivation for your reply, mandatory for the
>         "not support" and nice to have for the "support".____
> 
>         __ __
> 
>         __ __
> 
>         Thanks,____
> 
>         __ __
> 
>         Fatai & Daniele____
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>         <https://www.ietf.org/mailman/listinfo/ccamp>
> 
>     -- 
> 
>     /Network Solutions A//rchitect /
> 
>     /Email [email-masked] <mailto:[email-masked]>//
>     /
> 
>     /M 301 502-1347
> 
>     /
> 
> 
>     <https://www.ietf.org/mailman/listinfo/ccamp>
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 21 Jan 2022 21:49:08 +0000 (UTC)

Question: if I am to ask for a slice of a 3 layer cake with raspberries at the top, walnuts in the middle and pineapple at the bottom ( for SLOs) do I send the request to one or three separate places? If the latter, how do I know where from and from how many places the kitchen gets its walnuts?

  On Fri, Jan 21, 2022 at 3:00 PM, Joel M. Halpern<[email-masked]> wrote:   Under what circumstance, even if the customer knows (out of band) that 
the operator has OTN capability) would the customer somehow specify OTN 
specifics as part of requesting an end-to-end network slice (which 
inherently has to traverse more than the OTN?)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Jan 2022 17:05:15 -0500

Igor, you know better.  If youa re asking for a service to deliver IP or 
Ethernet packets, what would you do with a walnut?

Yours,
Joel

On 1/21/2022 4:49 PM, Igor Bryskin wrote:
> Question: if I am to ask for a slice of a 3 layer cake with raspberries 
> at the top, walnuts in the middle and pineapple at the bottom ( for 
> SLOs) do I send the request to one or three separate places? If the 
> latter, how do I know where from and from how many places the kitchen 
> gets its walnuts?
> 
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
> 
>     On Fri, Jan 21, 2022 at 3:00 PM, Joel M. Halpern
>     <[email-masked]> wrote:
>      > On Fri, Jan 21, 2022 at 3:26 AM Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >    Hi Adrian
>      >
>      >    On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel
>     <[email-masked] <mailto:[email-masked]>
>      >    <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >        Hi Fatai, Daniele,____
>      >
>      >        __ __
>      >
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>.____
>      >
>      >          Gyan> Agreed
>      >
>     <mailto:[email-masked]>
>      >        <mailto:[email-masked]
>     <mailto:[email-masked]>>> *On Behalf Of *Fatai Zhang
>      >
>      >
>      >        *To:* CCAMP <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >        <https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>>
>      >
>      >    --
>      >
>      >    <http://www.verizon.com/ <http://www.verizon.com/>>
>      >
>      >    *Gyan Mishra*
>      >
>      >    /Email [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>//
>      >    /
>      >
>      >    /M 301 502-1347
>      >
>      >    /
>      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
> 
>      >    <https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>>
>      >
>      >

---

From: Aihua Guo <[email-masked]>
Date: Fri, 21 Jan 2022 21:24:14 -0500

Hi Joel,

Thanks for your comments.

Section 2 of draft-zheng-ccamp-yang-otn-slicing describes several use cases
where a customer would potentially request an OTN slice with OTN-specific
SLOs. For example, in the use case for wholesale of optical resources, a
local OTN operator (as a customer) may rent from a large global operator an
OTN slice to serve its own traffic needs. The connectivity between the two
operators are OTN CE-PE and the OTN slice is expected to meet specific OTN
SLO requirements, such as bandwidth in terms of # and types of ODU
containers, and service performance in terms of bit error rates.

Thanks,
Aihua

On Fri, Jan 21, 2022 at 2:59 PM Joel M. Halpern <[email-masked]> wrote:

> >         <
> https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
> >
> >         <
> https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
> >
> >         <
> https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
> >.____
> >
> >          Gyan> Agreed
> >
> >     /Email [email-masked] <mailto:[email-masked]
> >//
> >     /
> >
> >     /M 301 502-1347
> >
> >     /
> >
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Jan 2022 21:35:35 -0500

It strikes me that we are abusing the term network slice rather badly 
across all of our use cases.

What you describe is an OTN service.  I has little or nothing to do with 
end-to-end network slicing.  (It can, of course, be used to fulfill 
portions of an end-to-end network slice, but so can lots of things.)

What you describe sound useful.  Wouldn't we be better of if we 
described it as what it is, rather than conflating it with IETF network 
slice (technology agnostic) or worse end-to-end network slices?

Yours,
Joel

On 1/21/2022 9:24 PM, Aihua Guo wrote:
> Section 2 of draft-zheng-ccamp-yang-otn-slicing describes several use 
> cases where a customer would potentially request an OTN slice with 
> OTN-specific SLOs. For example, in the use case for wholesale of optical 
> resources, a local OTN operator (as a customer) may rent from a large 
> global operator an OTN slice to serve its own traffic needs. The 
> connectivity between the two operators are OTN CE-PE and the OTN slice 
> is expected to meet specific OTN SLO requirements, such as bandwidth in 
> terms of # and types of ODU containers, and service performance in terms 
> of bit error rates.
> 
> Thanks,
> Aihua
> 
> On Fri, Jan 21, 2022 at 2:59 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>       <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/ <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>
>       <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/ <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>
>       <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/ <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>>.____
>      >
>      >          Gyan> Agreed
>      >

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 22 Jan 2022 14:59:49 -0500

Hi Aihua

>From a layering perspective and integration into TEAS IETF NS,  the
technology agnostic IETF NSC provisions the Network slice and interfaces
with RFC 8453 ACTN for provisioning of the abstraction of control functions
of underlay GMPLS In MPLS-TP transport domains VN Type 1 or Type 2 resource
based slice using MDSC and PSC controllers.  So with this draft we are
creating another layer -technology specific OTN-SC which  sits at the
southbound of the ACTN controller. Correct?

The OTN-SC interfaces at the southbound using the MDSC-to-PNC interface
(MPI) with a Physical Network Controller (PNC)

or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN
control framework [RFC8453
<https://datatracker.ietf.org/doc/html/rfc8453>].  The logical
function within the OTN-SC is responsible for translating the OTN
slice requests intoconcrete slice realization which can beunderstood
and provisioned at the
southbound by the PNC or MDSC.

So this is another provisioning layer being added that directly
interfaces between ACTN PNC / MSDC and the physical OTN underlay
optical layer DWDM equipment.

I do think the term “slice” being used is very confusing but I see now
that it’s taking the higher layer IETF network slice provisioning
model

and trying to augment and realize the overall solution realizing the
underlay OTN slice leveraging the existing ACTN framework.

So the question in my mind is if the additional OTN-SC layer is
necessary or not?

Responses In-line

Kind Regards

Gyan

> scenario with multiple options, as shown below:

   Gyan>  Section 3 describes the framework of network slicing but I don’t
see the three options as you have listed below.  Or is this embedded in the
Yang models.  Explicit verbiage showing the options would be good for the
reader.

>  Gyan> Understood.  Where is this option defined what section.
>
> Gyan> Understood.  I see that in section 3.  I think the confusion is that
> IETF network slice is technology agnostic and the OTN-SC is OTN technology
> specific.  Also question as to whether this additional layer interfacing
> with OTN to realize the IETF network slice is necessary or is it adding
> unnecessary complexity in provisioning the IETF network slice.
>
> Gyan> Where is Option 3 verbiage in the draft.  I don’t see it in section
> 3.  I think labeling the options would be helpful and maybe with a diagram.
>
> Gyan> I think what would be helpful to show maybe in a section that how
> this additional OTN-SC the value and gains it provides that is not already
> provided by ACTN framework RFC 8453.
>
>  Gyan> Many Thanks for the clarifications.  Thank you for reviewing my
> comments.
>
> Thanks,
>
> Aihua
>
>>> I think that CCAMP should work on YANG models for slicing OTN networks.
>>> I think that this draft forms a starting point and should be adopted, but

*Gyan Mishra*

*M 301 502-1347*

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Jan 2022 10:13:12 +0800

Gyan, Aihuu, et.al.,

On 23/01/2022 03:59, Gyan Mishra wrote:
> with RFC 8453 ACTN for provisioning of the abstraction of control 
> functions of underlay GMPLS In MPLS-TP transport domains VN Type 1 or 
> Type 2 resource based slice using MDSC and PSC controllers. 

Why is that MPLS/TP specific, woulodn't it wprk exactly the same if you 
wanted to establish VN Type 1 or Type 2 if the network on top of the 
GMPLS were MPLS?

/Loa

  So with
> this draft we are creating another layer -technology specific OTN-SC 
> which  sits at the southbound of the ACTN controller. Correct?
> 
> or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN control framework [RFC8453  <https://datatracker.ietf.org/doc/html/rfc8453>].  The logical function within the OTN-SC is responsible for translating the OTN slice requests intoconcrete slice realization which can beunderstood and provisioned at the
> So this is another provisioning layer being added that directly interfaces between ACTN PNC / MSDC and the physical OTN underlay optical layer DWDM equipment.
> 
> 
> I do think the term “slice” being used is very confusing but I see now that it’s taking the higher layer IETF network slice provisioning model
> 
> and trying to augment and realize the overall solution realizing the underlay OTN slice leveraging the existing ACTN framework.
> 
> 
> So the question in my mind is if the additional OTN-SC layer is necessary or not?
> 
> 
> Responses In-line
> 
> 
> Kind Regards
> 
> 
> Gyan
> 
> 
> On Fri, Jan 21, 2022 at 2:07 PM Aihua Guo <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Gyan,
> 
>     slicing, i.e. IETF NS can be used to specify slice requests
>     regardless of underlay network technologies - whether it being IP or
>     OTN. Actually, in draft-zheng-ccamp-yang-otn-slicing, Figure 2
>     describes the support for this scenario with multiple options, as
>     shown below:
> 
>     Gyan>  Section 3 describes the framework of network slicing but I 
> don’t see the three options as you have listed below.  Or is this 
> embedded in the Yang models.  Explicit verbiage showing the options 
> would be good for the reader.
> 
> 
>     mechanisms, such as L1VPN, abstract TE topologies, TE tunnels, or
>     any proprietary technologies the controller chooses to use. In this
>     case, the OTN-SC NBI is not used.__
> 
>     __ Gyan> Understood.  Where is this option defined what section.__
> 
>     request and delegates the request to the OTN-SC by using the OTN
>     slicing interface at the OTN-SC NBI. The OTN-SC NBI is technology
>     specific and augments the IETF NSC NBI. Therefore, the IETF NSC
>     request to OTN-SC can be either technology agnostic or OTN specific
>     depending on the realization of IETF NSC. The OTN-SC will in turn
>     work with the PNC and realize the slice. In this option, OTN-SC is
>     essentially a subordinate slice controller of the IETF NSC which
>     also meets the hierarchical nature of slice control as described in
>     the network slice framework document.
> 
>     __
> 
>     __Gyan> Understood.  I see that in section 3.  I think the confusion
>     is that IETF network slice is technology agnostic and the OTN-SC is
>     OTN technology specific.  Also question as to whether this
>     additional layer interfacing with OTN to realize the IETF network
>     slice is necessary or is it adding unnecessary complexity in
>     provisioning the IETF network slice.__
> 
>     Both Option 1 and Option 2 are in line with the view that a customer
>     can request a technology-agnostic NS and the IETF-NSC can realize
>     the slice in its underlay networks whether it being OTN or packet.____
> 
> 
>     Additionally, */_Option 3: _/* a customer who is OTN-aware may use
>     the augmented OTN-SC NBI to request an OTN slice with OTN-specific
>     SLOs (e.g. BER, bandwidth in terms of the # of time slots), and the
>     OTN SC realizes the slice by working with the underlying PNC(s) in
>     single- or multi-domain network scenarios. Several use cases for
>     option 3 are also described in the draft.
> 
>     Gyan> Where is Option 3 verbiage in the draft.  I don’t see it in
>     section 3.  I think labeling the options would be helpful and maybe
>     with a diagram.
> 
>     To summarize, the OTN slicing model provides a service-intent
>     interface that supports the configuration of OTN slices, which can
>     be realized by the OTN-SC controller in various ways. The OTN SC
>     also allows an OTN-aware customer to create OTN slices with
>     OTN-specific SLOs.
> 
>     __Gyan> I think what would be helpful to show maybe in a section
>     that how this additional OTN-SC the value and gains it provides that
>     is not already provided by ACTN framework RFC 8453. __
> 
>     make further clarifications in the document to align with the
>     framework of IETF network slicing.__
> 
>     __ Gyan> Many Thanks for the clarifications.  Thank you for
>     reviewing my comments.__
> 
>     Thanks,____
> 
>     Aihua
> 
> 
>         I agree with all your comments related to this draft especially
>         the complexity with this approach as compared to ACTN
>         architecture.  One critical  point you make is that the slice
>         service should be independent of underlay technology.  As OTN is
>         a component of the underlay it goes against the agnostic slice
>         approach taken with IETF Network Slice.
> 
>         Others have mentioned the same related to underlay technology
>         slice added complexity and does that mean a different  slice
>         Yang model for each L1 Technology “Bottoms Up” approach. 😁
> 
>         Comments in-line
> 
>         Kind Regards
> 
>         Gyan
> 
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Fatai, Daniele,____
> 
>             __ __
> 
>             I think that CCAMP should work on YANG models for slicing
>             OTN networks. I think that this draft forms a starting point
>             and should be adopted, but like Igor, “I have questions”.____
> 
>             fixed. (This is normal, but it is worth highlighting in view
>             of my thoughts, below).____
> 
>             __
> 
>             I am particularly interested to look at harmonising this
>             work with draft-ietf-teas-applicability-actn-slicing and
>             (I appreciate the work the authors have done to synchronise
>             with draft-ietf-teas-ietf-network-slices).
> 
>               Gyan> Agreed
> 
>             The point being that “The definition of an IETF Network
>             Slice Service is independent of the connectivity and
>             technologies used in the underlay network”
>             [draft-ietf-teas-ietf-network-slices] meaning that the NBI
>             in this model could be a technology-specific augmentation of
>             complexity of interfaces and controllers shown in Figure 2,
>             when Figure 1 of draft-ietf-teas-applicability-actn-slicing
>             considers a more simple mapping between the slicing and ACTN
>             We might also debate the meaning of “E2E Slice Controller”
>             since this term is not mentioned anywhere except in Figure 2
>             and only appears once in draft-ietf-teas-ietf-network-slices
>             (in Figure 2) that appears to have escaped being cleaned up.____
> 
>             __ __
> 
>             But, I think these are questions that can be easily resolved
>             in discussions within the WG, so adoption should be safe.____
> 
>             __ Gyan> Agreed __
> 
>             Best,____
> 
>             Adrian____
> 
>             __ __
> 
>             PS. At some stage the AD is going to ask, “Please find a way
>             to reduce the front page authors to 5 or fewer.” Experience
>             suggests that it is easier to do this sooner rather than
>             later, and it is better if the authors resolve that rather
>             than requiring the chairs to force the point.____
> 
>             __ __
> 
>             draft-zheng-ccamp-yang-otn-slicing-03 have been collected,
>             this starts the polling for WG adoption.____
> 
>             __ __
> 
>             Please send email to the list indicating "yes/support" or
>             "no/do not support" and a motivation for your reply,
>             mandatory for the "not support" and nice to have for the
>             "support".____
> 
>             __ __
> 
>             __ __
> 
>             Thanks,____
> 
>             __ __
> 
>             Fatai & Daniele____
> 
>             __ __
> 
>             __ __
> 
>             __ __
> 
>         <mailto:[email-masked]>//
>         /
> 
>         /M 301 502-1347
> 
>         /
> 
> 

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Aihua Guo <[email-masked]>
Date: Mon, 24 Jan 2022 12:03:30 -0500

Hi Gyan,

Thanks for your comments. I agree with your observation that OTN-SC is
"taking the higher layer IETF network slice provisioning modeland trying to
augment and realize the overall solution realizing the underlay OTN slice
leveraging the existing ACTN framework".

The use of OTN-SC is also in line with the IETF network slice framework
defined in draft-ietf-teas-ietf-network-slices-05, which states that, "an
IETF NS may be combined hierarchically, so that a network slice may itself
be sliced. They may also be combined sequentially so that various different
networks can each be sliced and the network slices placed into a sequence
to provide an end-to-end service". In this case, OTN-SC serves as a
sub-slice controller to the IETF NSC for provisioning OTN slices in
underlying OTN domains to support end-to-end network slicing. Section 2.5
of draft-zheng-ccamp-yang-otn-slicing describes this scenario, which can be
made clearer based on your suggestions.

I also agree that it would be beneficial for this draft to clearly mark the
different options provided by the OTN-SC in both the descriptions and the
picture, as you suggested below. Will incorporate those improvements in the
next draft revision.

Thanks,
Aihua

On Sat, Jan 22, 2022 at 3:00 PM Gyan Mishra <[email-masked]> wrote:

>> *Option 1:* the IETF NSC receives a technology-agnostic slice request,
>> it uses MPI to realize the slice on PNC using available mechanisms, such as
>> *Option 2:* the IETF NSC receives a technology-agnostic slice request
>> and delegates the request to the OTN-SC by using the OTN slicing interface
>> at the OTN-SC NBI. The OTN-SC NBI is technology specific and augments the
>> IETF NSC NBI. Therefore, the IETF NSC request to OTN-SC can be either
>> technology agnostic or OTN specific depending on the realization of IETF
>> NSC. The OTN-SC will in turn work with the PNC and realize the slice. In
>> this option, OTN-SC is essentially a subordinate slice controller of the
>> IETF NSC which also meets the hierarchical nature of slice control as
>> described in the network slice framework document.
>>
>> Gyan> Understood.  I see that in section 3.  I think the confusion is
>> that IETF network slice is technology agnostic and the OTN-SC is OTN
>> technology specific.  Also question as to whether this additional layer
>> interfacing with OTN to realize the IETF network slice is necessary or is
>> it adding unnecessary complexity in provisioning the IETF network slice.
>>
>>> added complexity and does that mean a different  slice Yang model for each
>>> L1 Technology “Bottoms Up” approach. 😁
>>>
>>> Comments in-line
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>>> Another question is why there is the need to introduce the complexity
>>>> of interfaces and controllers shown in Figure 2, when Figure 1 of draft-ietf-teas-applicability-actn-slicing
>>>> draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts the
>>>> polling for WG adoption.
>>>>
>>>>
>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 Jan 2022 20:06:12 -0500

Hi Aihua

Very welcome.

Comments in-line

> Thanks for your comments.

   Gyan> Ack

I agree with your observation that OTN-SC is "taking the higher layer IETF
> network slice provisioning modeland trying to augment and realize the
> overall solution realizing the underlay OTN slice leveraging the existing
> ACTN framework".
>

    Gyan> Ack

> to provide an end-to-end service".  I did not see it mentioned but maybe
> add reference to the verbiage above in the draft and help provide reasoning
> for using the word “slice”.
>

    Gyan> Understood

In this case, OTN-SC serves as a sub-slice controller to the IETF NSC for
> provisioning OTN slices in underlying OTN domains to support end-to-end
> network slicing. Section 2.5 of draft-zheng-ccamp-yang-otn-slicing
> describes this scenario, which can be made clearer based on your
> suggestions.
>

    Gyan> Thank you

>
> I also agree that it would be beneficial for this draft to clearly mark
> the different options provided by the OTN-SC in both the descriptions and
> the picture, as you suggested below. Will incorporate those improvements in
> the next draft revision.
>

    Gyan> That would be very helpful for the reader as well as clearly
defining the OTN slice specification.

Gyan> It maybe a good idea to add verbiage in the draft as to OTN slice
provisioning gap that exists for network slicing compared to ACTN
provisioning of underlay VN Type 1 and Type 2 OTN resources.

>>> slicing, i.e. IETF NS can be used to specify slice requests regardless of
>>> underlay network technologies - whether it being IP or OTN. Actually, in
>> don’t see the three options as you have listed below.  Or is this embedded
>> in the Yang models.  Explicit verbiage showing the options would be good
>> for the reader.
>>
>>>
>>>                          +--------------------+
>>>
>>>                          | Provider's User    |
>>>
>>>                          +--------|-----------+
>>>
>>>                                   | CMI
>>>
>>> section 3.  I think labeling the options would be helpful and maybe with a
>>> diagram.
>>>
>>> make further clarifications in the document to align with the framework of
>>> IETF network slicing.
>>>
>>>>> networks. I think that this draft forms a starting point and should be
>>>>> adopted, but like Igor, “I have questions”.
>>>>>
>>>> The point being that “The definition of an IETF Network Slice Service
>>>>> is independent of the connectivity and technologies used in the underlay

*Gyan Mishra*

*M 301 502-1347*