Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

[Dhruv Dhody <[e-mail]>]

Hi,

This is a consolidated reply to multiple messages. I have snipped to the
key points. Apologies if I missed some.
<https://notes.ietf.org/#Sergio-said0>Sergio said

Originally when VN model was presented in a couple of IETF meeting, the
YANG model was completely decoupled from TEAS topology, but comments from
most of TEAS WG, was to avoid defining “new YANG constructs” and instead to
use what we have already in TEAS topology, and the authors have updated the
model accordingly. This comment applies also to the YANG model for IETF
network slicing.

[Dhruv]: I agree with the history but disagree with the conclusion :)

The main objective is to model based on the definition and framework of the
IETF network slices (which does not describe the IETF network slice in
terms of VN, AP, VNAP…).

The modeling approach we used is more akin to a fully independent LxSM
model that does not describe the service in terms of topology. Further, we
wanted to avoid any coupling with TE models as there are other ways to
realize slice such as MT, FlexAlgo, etc. So to do a tight coupling with TE
topo for the IETF network slice would be a mistake.

Based on another comment from the TEAS WG,the term ACTN has also been
removed from the draft not to limit the VN YANG model applicability only to
ACTN. Therefore, it is possible to use the VN YANG model also in other
networks.

[Dhruv]: As of the current state of the models, the tight coupling with TE
topo is a hindrance.

There is a current on going draft in TEAS, that I like and contribute,
https://www.ietf.org/archive/id/draft-busi-teas-te-topology-profiles-02.txt,
that already describe how TEAS topology can be profiled to address not TE
network.

[Dhruv]: That would be nice, but the key here is to define IETF network
slice service independently and not in the terms of a topology (same as
LxSM).

This model defines the customer view (intent?) of the IETF network slice in
the easiest terms independently without the extra baggage!
<https://notes.ietf.org/#Xueyan-said>Xueyan said

If there is existing technology (such as ACTN VN, L2SM, L3SM, TE YANG,
etc.) can be reused with necessary augmentations for the realization of NSC
NBI YANG, we should refer to them but not to specify a new one.

[Dhruv]: Surely, if the WG thought there is a need for new concepts and
terms to describe IETF network slices in draft-ietf-teas-network-slices, it
is logical to model them on their own. Yes, they have a similar structure,
but that is normal for most of the service models.
<https://notes.ietf.org/#Kenichi-asked>Kenichi asked

why don’t we discuss to enhance/augment an existing nbi as the nbi solution?

[Dhruv]: We did try to capture this in the Appendix. It's clear that we
need to bring that discussion back up into the main text on the design
philosophy behind this model.

   - The VN model is tightly coupled with TE topology. The IETF network
   slice can be realized with non-TE techniques such as FlexAlgo/MT and thus
   any tight coupling is not acceptable.
   - The constraints (which are TE specific) are buried deep inside the TE
   topology abstract node connectivity matrix and do not map easily with
   SLO/SLE.
   - The IETF network slice endpoint is not described in terms of AP/VNAP
   and thus does not map with ease.

According to Figure 1 of draft-king-teas-applicability-actn-slicing-10, NSC
NBI can be replaced with CMI. If the new nbi is created, we have to
parallelly implement two nbis or just wrap CMI with NSC NBI. From one of
mobile operators’ capex perspective, we don’t want to do such effort, since
we believe major ietf network slice requirements can be covered by ACTN.

[Dhruv]: CMI is not one YANG model, there are a bunch of them
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-yang-08#section-4.1>
already.
Our model could join the group. One would use this technology (and TE)
agnostic model only if it needs to, if the existing set of
technology-specific models are found to be appropriate by the consumer it
is perfectly fine to use that interface. It is akin to use the slice
realization technique directly. The key is that there is a gap identified
for the technology-agnostic model and this fills that gap.

We’re wondering what’s difficulty to augment the VN model.

[Dhruv]: See above. We plan to also document them in the draft.
<https://notes.ietf.org/#Young-said>Young said

One resolution I can think of would be to combine the two models into one
single model. I believe this is still possible from a modeling standpoint.
This may result in some delay for implementation, yet this option might be
much better than having two standards models.

[Dhruv]: You could do that if we go back and redesign the whole thing and
also define the IETF network slicing concepts in terms of VN and AP/VNAP. I
don't think that's a good idea!
<https://notes.ietf.org/#Daniele-pointed-out-in-the-other-thread>Daniele
pointed out in the other thread

If multiple options are acknowledged by the WG, then there should be a
document saying something like:

In case X, option A should be used
In case Y, option B should be used
In case Z, options A and C should be used

[Dhruv]: That is a good suggestion. At least in this document, we can add
where do we see a need for a technology-agnostic model and how it does not
mean that this NBI is the only way to deliver the IETF network slice
service!

Have a good weekend!

Thanks!
Dhruv

On Tue, Sep 14, 2021 at 5:39 PM Vishnu Pavan Beeram <[e-mail]>
wrote:

> WG,
>
> Clearly, there needs to be more discussion on this topic before we can
> draw consensus on the progress of this document. There will be
> dedicated time set aside at the upcoming interim meeting (Sept 27th)
> to debate the approach advocated in this draft (define a new service
> model from scratch) and other alternatives specified on the list
> (use ietf-vn as is; define a new service model by augmenting ietf-vn).
>
> The authors of draft-wd-teas-ietf-network-slice-nbi-yang will have a
> slot in the interim to reiterate their rationale for choosing the current
> approach. If anyone wants to present a counter approach, please do
> send in a slot request.
>
> In the meantime, we do expect the debate/discussion to continue
> on this thread.
>
> Regards,
> Pavan and Lou
>
> On Fri, Aug 27, 2021 at 10:07 AM Vishnu Pavan Beeram <
> [e-mail]> wrote:
>
>> All,
>>
>> This is start of a *two* week poll on making
>> draft-wd-teas-ietf-network-slice-nbi-yang-04 a TEAS working group
>> document.
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".
>> If indicating no, please state your reservations with the document. If
>> yes, please also feel free to provide comments you'd like to see
>> addressed once the document is a WG document.
>>
>> The poll ends September 10th.
>>
>> Thank you,
>> Pavan and Lou
>>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>