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

[Aihua Guo <[e-mail]>]

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 <[e-mail]> wrote:

> 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*
>
>