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

["Wubo (lana)" <[e-mail]>]

Hi Kenichi,

Regarding VNAPs and APs, see inline please.

Thanks,
Bo
发件人: Teas [mailto:[e-mail]] 代表 Ogaki, Kenichi
发送时间: 2021年9月20日 12:54
收件人: Dhruv Dhody <[e-mail]>; TEAS WG <[e-mail]>
主题: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Dhruv,

Thanks for your reply.

See comments inline [KO], please.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, September 18, 2021 12:38 AM
To: TEAS WG
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04


Hi,

This is a consolidated reply to multiple messages. I have snipped to the key points. Apologies if I missed some.

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!

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.

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.

[KO] So, Xufeng and Sergio are proposing to augment to support draft-busi-teas-te-topology-profiles ond/or draft-liu-teas-transport-network-slice-yang. I believe it may be enough to augment the reference of /virtual-network/vn/abstract-node to /nw:networks/network/node/node-id only for this purpose.





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

[KO] To request a slice creation with SLO/SLE, vn-compute/input/path-constraints can be used(augmented). We believe it's better to also define path-constraints under /virtual-network/vn and /virtual-network/vn/vn-menber not only for this discussion, but also for the current TE-specific VN model itself.



  *   The IETF network slice endpoint is not described in terms of AP/VNAP and thus does not map with ease.

[KO] I believe AP/VNAP and ns-endpoint are abstract concepts relating to AC. And, the AC itself must be instantiated as a technology specific instance like that of LxSM. Then, we believe even the current NBI draft must support the same mechanism as te-service-mapping, since it's painful to support all the technology specific AC inside the model as the current structure tries to do so. I already commented to Bo.

https://mailarchive.ietf.org/arch/msg/teas/pr0dd6lDeM3HgU_EFNx18dN4eKo/



The current actn-vn-yang just says:



Characteristics of Access Points (APs) that describe customer'send point characteristics



Characteristics of Virtual Network Access Points (VNAP) that describe how an AP is partitioned for multiple VNs sharing the AP and its reference to a Link Termination Point (LTP) of the Provider Edge (PE) Node;



[Bo] My reading of actn-vn-yang is, APs refer to TPs (termination point) of IETF topology model, so are one-to-one relationship to ACs, and one or multiple APs may be assigned at the same customer demarcation point for protection purpose. And VNAPs refer to LTPs of PEs. VN uses the connection matrix between APs to describe the service topology of a VN.

This modeling approach requires that the customer know the detailed AC connection topology of the provider.

But network slicing service does not require customers to know these detailed topology information. Similar to L3SM describing service requirements of sites, slice service customer only need to describe service requirements between NSEs.



Regards,

Bo



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.

[KO] Our intention already replied to Adrian.

https://mailarchive.ietf.org/arch/msg/teas/u3CoWGeNNjZaazICVdWAKtGNdZc/


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

[Dhruv]: See above. We plan to also document them in the draft.

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!

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas