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

[Aihua Guo <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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
>> 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
>
>> 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?
>>
>    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 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 <[e-mail]> *On Behalf Of *Fatai Zhang
>>
>>
>> *Sent:* 12 January 2022 02:24
>> *To:* CCAMP <[e-mail]>
>> *Subject:* [CCAMP] WG adoption poll on
>> draft-zheng-ccamp-yang-otn-slicing-03
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>