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

[Gyan Mishra <[e-mail]>]

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


On Fri, Jan 21, 2022 at 2:07 PM Aihua Guo <[e-mail]> 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:
>

   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.

>
>                          +--------------------+
>
>                          | 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.
>
>  Gyan> Understood.  Where is this option defined what section.
>
> *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.
>
> 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.
>
> 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.
>
>  Gyan> Many Thanks for the clarifications.  Thank you for reviewing my
> comments.
>
> 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
>>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*