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

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 2 Sep 2021 07:59:55 +0000

Hi All,

No/not support.

We basically agree with Daniele's opinion.

As we commented to "[Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt" thread, we totally agree that the slice nbi should be underlying technology agnostic.
However, why don't we discuss to enhance/augment an existing nbi as the nbi solution?

Adrian commented to "[Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10" thread.
>All the text you quoted says is, “You can use ACTN to achieve network slicing in networks that support ACTN.

If so, does TEAS WG use ACTN to achieve network slicing in networks that support ACTN?
We understand that WG draft adoption poll of "draft-king-teas-applicability-actn-slicing" is dealt in the scope of ietf network slice standardization. The result shouldn't be that it's up to you.

Anyway, the followings are our concerns.

1) 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.

2) As we discussed in "[Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt" thread, ns-endpoint must be technology specific. The current model definition of draft-wd-teas-ietf-network-slice-nbi-yang-03 isn't enough, and we believe that the same approach with te-service-mapping for L1/2/3 AC is necessary to do so.

>> >(2) It is true that the data nodes that characterize the slice
>> service within the slice provider are technology-agnostic, but aren't 
>> for the CE-PE attachment as this conditions how the service is 
>> delivered.
>> 
>> We totally agree with you. Inside a slice, technology should be 
>> agnostic, but the demarcation point inside/outside the slice cannot 
>> avoid being technology specific.
>
>[Med] Glad to see we are in agreement.

3) draft-ietf-teas-ietf-network-slices-04 introduced the requirement of connectivity matrix. Similarly, p2p based ns-connections model definition of draft-wd-teas-ietf-network-slice-nbi-yang-04 isn't enough, and we believe that the same approach for connectivity matrix in ACTN is necessary.

4) Although not defined in draft-ietf-teas-ietf-network-slices-04, as we commented in "[Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt" and "[Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt" threads, we believe a feasibility check functionality should be defined from the other SDO's requirement, especially for 3GPP slice. This should be the same functionality as VN-compute in actn-vn-yang.

To solve above 2) - 4) requirements, we must create a copy of actn-vn-yang just with different data node names.
If so, again, why don't we enhance/augment actn-vn-yang?

In terms of Tarek's following comment in "[Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10" thread, 
>However, today other standalone service models such as L3SM and L2SM exist independent of ACTN or VN models.
>
>In fact, the VN draft < draft-ietf-teas-actn-vn-yang>, explicitly mentions that the VN model can co-exist with such service models (see below).

The requirements to L2/3SM model and actn-vn-yang are totally different. Not just parallelly coexisting, but depending on each other as Daniele wrote.

All the best,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: Tuesday, August 31, 2021 10:16 PM
To: Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Pavan, WG,

”no/do not support”. 

We’re polling at the same time two drafts, one of which says how to use ACTN for network slicing and the other explaining why ACTN is not used for the network slicing NBI.

In my opinion this is a conflict that should be resolved before adoption.

BR
Daniele  

From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: den 27 augusti 2021 17:07
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

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

---

From: <[email-masked]>
Date: Thu, 2 Sep 2021 11:22:58 +0000

Hi Pravan, all,

I support this draft.

That’s said, I still have some concerns with the structure/content that I did already shared on the list. I trust the author will address those.

Cheers,
Med

De : Teas [mailto:[email-masked]] De la part de Vishnu Pavan Beeram
Envoyé : vendredi 27 août 2021 17:07
À : TEAS WG <[email-masked]>
Cc : TEAS WG Chairs <[email-masked]>
Objet : [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

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.

Thank you,
Pavan and Lou

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: 韩博文(联通集团中国联通研究院-本部) <[email-masked]>
Date: Mon, 6 Sep 2021 06:25:30 +0000

Hi  WG,
I support the adoption of this draft .

Best regards,
Bowen
________________________________
韩博文
单位：中国联通研究院 网络技术研究中心
手机：18610920160

From: Vishnu Pavan Beeram<mailto:[email-masked]>
Date: 2021-08-27 23:07
To: TEAS WG<mailto:[email-masked]>
CC: TEAS WG Chairs<mailto:[email-masked]>
Subject: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04
All,

Thank you,
Pavan and Lou
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: <[email-masked]>
Date: Tue, 7 Sep 2021 11:29:30 +0800 (CST)

Hi all,

"no/do not support".

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.

Best regards,
Xueyan

------------------原始邮件------------------
发件人：VishnuPavanBeeram
收件人：TEAS WG;
抄送人：TEAS WG Chairs;
日 期 ：2021年08月27日 23:07
主 题 ：[Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04
_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

All,

Thank you,
Pavan and Lou

---

From: "韩柳燕" <[email-masked]>
Date: Fri, 10 Sep 2021 13:14:15 +0800

Hi WG,

I support the adoption of this draft. 

Best regards,
Liuyan

2021-09-10 

-------------------------------------
韩柳燕 / Han Liuyan
中国移动通信研究院 网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33076
传真：010-63601087
手机: 15810339103
Email: [email-masked]
------------------------------------- 

发件人： Vishnu Pavan Beeram 
发送时间： 2021-08-27  23:14:04 
收件人： TEAS WG 
抄送： TEAS WG Chairs 
主题： [Teas] WG Adoption Poll -draft-wd-teas-ietf-network-slice-nbi-yang-04 
 
All,

Thank you,
Pavan and Lou

---

From: tom petch <[email-masked]>
Date: Fri, 10 Sep 2021 09:24:54 +0000

From: Teas <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 07 September 2021 04:29

<tp>

No do not support

As Daniele pointed out, and this e-mail says,  the case for a new module does not seem to have been made.

I have a number of comments relating to the YANG module, the most significant being the choice of prefix, but they can wait until this issue is resolved.

Hi all,

"no/do not support".

Best regards,
Xueyan

------------------原始邮件------------------
发件人：VishnuPavanBeeram
收件人：TEAS WG;
抄送人：TEAS WG Chairs;
日 期 ：2021年08月27日 23:07

All,

Thank you,
Pavan and Lou

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Fri, 10 Sep 2021 10:00:29 +0000

Hi Pavan, all

"no/do not support".

I share the comments I read from Daniele and Kenichi.

In the draft draft-king-teas-applicability-actn-slicing-10  in the already cited 4.1 section it is written

“The ACTN VN model is a generic virtual network service model that allows consumers to specify a VN (i.e., network slice) that meets the consumer's service objectives with various constraints on how the service is delivered”

Fine, what is missed here to support a slice “definition”?

In the draft-wd-teas-ietf-network-slice-nbi-yang-04 is mentioned the limitation of VN model due to his bound to TE topology.
Well , here 3 things :

  1.  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.
  2.  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.
  3.  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.

In draft-wd is also mentioned another potential limitation of VN model related to end point and SLO:  “the Network Slice SLO and Network Slice Endpoint are not clearly defined
End point in VN model area described using AP and VNAP, extensively described also in RFC 8453, sincerely I do not see what is missing.
For SLO, if something is missing , it seems to me not a big deal to “augment” the model for SLO, and also beneficial for ACTN in general independently of network slicing scenarios.
On the other side also the authors in draft-wd is explicitly have wrote that the SLO list is not complete and other parameters can be added ,btw actual SLO is strictly packet  oriented in my view.

It is worthwhile also clarifying that in the VN model it is used TEAS topology to describe the network as abstract node and connectivity matrix to express edn-to connectivities, but even in type 2 case, the reference topology is an abstract topology that has nothing to do with the underlying topology , that need to be used when there is slice realization.  So we are talking about VN “intent” not VN realization.

In conclusion my position is that before to propose an alternative model to do the same thing, it would be good to analyze possible missing information in the present VN model, maybe improving it , instead to create confusion proposing a new solution.

Thanks
Sergio

Sent: Friday, August 27, 2021 5:07 PM

All,

Thank you,
Pavan and Lou

---

From: Young Lee <[email-masked]>
Date: Fri, 10 Sep 2021 21:56:45 +0900

Hi Pavan,

No/do not support.

I concur with those who expressed their concern on the potential confusion
due to having two WG models (provided that this nbi-yang draft would be
accepted) for a similar purpose.

It would have been nicer if the authors of the two drafts would have had
chances to discuss for a potential resolution.

Augmentation of the VN model doesn't seem possible, however, as the VN
model is more particular model (i.e., TE model) than the nbi-yang model. If
my reasoning is wrong, please correct me.

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.

My two cents,
Young

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 13 Sep 2021 02:19:11 +0000

Hi Young and Dhruv,

>Augmentation of the VN model doesn't seem possible, however, as the VN model is more particular model (i.e., TE model) than the nbi-yang model. If my reasoning is wrong, please correct me.

https://mailarchive.ietf.org/arch/msg/teas/0pnjDhIDcKuHnwsjUBvnbB80Gys/
>Anyways. the authors did explore with the WG why augmenting the VN model was problematic because of the tight coupling with TE topology.

We're wondering what's difficulty to augment the VN model. Could you clarify this, since I believe you are main authors of VN model?
We agree that some detailed part of VN model are referred to te-topo model, and just recognize "ltp", "abstract-node" and "connectivity-matrix-id".

However, we totally agree with Sergio's comments in the previous mail.

If the problem is above wrote, we should just enhance or augment "abstract-node" to be able to choose more abstracted or a different type of topology, not only te-topo, for example.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Young Lee
Sent: Friday, September 10, 2021 9:57 PM
To: Vishnu Pavan Beeram <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Pavan,

No/do not support. 

I concur with those who expressed their concern on the potential confusion due to having two WG models (provided that this nbi-yang draft would be accepted) for a similar purpose. 

It would have been nicer if the authors of the two drafts would have had chances to discuss for a potential resolution. 

Augmentation of the VN model doesn't seem possible, however, as the VN model is more particular model (i.e., TE model) than the nbi-yang model. If my reasoning is wrong, please correct me.

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. 

My two cents,
Young

2021년 8월 28일 (토) 오전 12:07, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]> >님이 작성:

	All,

	
	Thank you,
	Pavan and Lou
	
	_______________________________________________
	Teas mailing list
	[email-masked] <mailto:[email-masked]> 
	https://www.ietf.org/mailman/listinfo/teas

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 13 Sep 2021 19:28:41 +0000

Hi all,

Yes/Support.

In my opinion an IETF Network Slice has special characteristics which can require a different model to express them. For instance, SLEs as the ones described by now in draft-ietf-teas-ietf-network-slices (i.e., isolation, security, etc) could imply different mappings later on existing models (or maybe different kind of augmentations, if the capabilities do not exist already) when choosing a specific technology or architectural framework for slice realization.

An example of this could be the case of the VN as discussed in this thread. A slice requested with a Network Slice model with SLOs/SLEs as expected by slice customers could use e.g. the auto-creation capability at MDSC for later realization following ACTN architecture. Part of the SLEs could be maybe out of the VN model, but yet relevant for the slice realization. That is why an specific model could be needed.

Being said that, I would advocate for a consistent definition of draft-wd-teas-ietf-network-slice-nbi-yang and draft-liu-teas-transport-network-slice-yang since they represent two alternatives for slice request that could be expected to be found at the NBI of the Network Slice Controller (as described in draft-contreras-teas-slice-controller-models). In essence, align/integrate both models.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Vishnu Pavan Beeram
Enviado el: viernes, 27 de agosto de 2021 17:07
Para: TEAS WG <[email-masked]>
CC: TEAS WG Chairs <[email-masked]>
Asunto: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

All,

Thank you,
Pavan and Lou

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 14 Sep 2021 07:09:03 -0500

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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 15 Sep 2021 01:41:54 +0000

Hi Luis and All,

I believe we are on the same page, but the approach is a little bit different.

See a few comments inline[KO], please.

Thanks,

Kenichi

From: Teas <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, September 14, 2021 4:29 AM
To: Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi all,

Yes/Support.

[KO] Agree.

[KO] We aren't saying the existing VN model can completely cover ietf network slice requirements as it is, but can enhance/augment to meet the requirements.

The question is what's the fatal problem for the VN model to *enhance/augment* to meet the requirements?

In terms of SLE, draft-wd-teas-ietf-network-slice-nbi-yang model definition is dealing with it as same as SLO, slo-sle-policy, then we also believe no big deal to augment as Sergio commented.

https://mailarchive.ietf.org/arch/msg/teas/5vQOGL-za1CwPgZb-pd9tyr09hE/

This is non-exhaustive list, but the two models have similar structures/objectives and we believe these are replaceable with enhancement/augmentation.

draft-wd-teas-ietf-network-slice-nbi-yang : actn-vn-yang

------------------------------------------------------------

network-slices/network-slice : virtual-network/vn

network-slices/network-slice/ns-slo-sle-policy : vn-compute/input/path-constraints

network-slices/network-slice/ns-endpoints/ns-endpoint : access-point/ap/vn-ap

network-slices/network-slice/ns-connections : virtual-network/vn/vn-member

[KO] We agree with draft-liu-teas-transport-network-slice-yang or draft-busi-teas-te-topology-profiles concept should be introduced if te-topo model is closely tied to TE specific technology.

Best regards

Luis

All,

Thank you,
Pavan and Lou

---

From: <[email-masked]>
Date: Thu, 16 Sep 2021 10:02:59 +0000

Hi Kenichi, all,

Thank you for clarifying the concerns you have with the NBI draft and for providing a concrete example. However:

* The network slice service is not necessarily a VN service. This needs to be further clarified in the slice framework draft.
* I do think that we need to keep in mind the role of the NBI and CLEARLY distinguish it from any technical realization of a network slice and also with narrow definitions of a slice (VN-specific with TE).
* A network slice service can be mapped, for example, to L3NM and/or L2NM without having to go through a VN mapping step (following, e.g., the framework in Section 3.1 of RFC8969).

* The “draft-wd-teas-ietf-network-slice-nbi-yang : actn-vn-yang ” structure you listed below may suggest that we could do the same exercise with L2VPN/L3VPN but we didn’t. We do have L3SM and L2SM because there are specifics to these services that are captured in these models. Slice service specifics should be captured in the NBI draft as well (I already raised this concern for the current NBI draft, but this does not prevent to adopt and work to fix that).
* Please note that draft-ietf-teas-actn-vn-yang says the following:

   The VN YANG model can be easily augmented to support the mapping of
   VN to the Services such as L3SM and L2SM as described in
   [I-D.ietf-teas-te-service-mapping-yang].

That text can be updated to cover the vn-slice mapping.

* One last point for which I support the nbi draft rather than relying upon the vn one is related to https://datatracker.ietf.org/ipr/4215/.

Thank you.

Cheers,
Med

De : Teas [mailto:[email-masked]] De la part de Ogaki, Kenichi
Envoyé : mercredi 15 septembre 2021 03:42
À : LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Cc : TEAS WG Chairs <[email-masked]>
Objet : Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

[[snip>>

---

From: Tarek Saad <[email-masked]>
Date: Thu, 16 Sep 2021 14:15:56 +0000

Hi Kenichi/all,

I believe a vanilla IETF network slice service NBI data model (without VN data model augmentation) and that is aligned completely with the network slice definition terminology in draft-ietf-teas-ietf-network-slice-definition is preferrable. The authors of draft-ietf-teas-ietf-network-slice-definition have done a great/tedious job of defining and aligning terminology specific to network slicing.
I’m afraid creating another mapping (see extract from your email below – and this is not an exhaustive list) just to enable augmentation is not desirable and will lead to confusion and make situation worse.
For someone already using ACT framework, I understand a desire to extend it for network slicing, but forcing it on any customer/intent interface would IMO be undesrirable.

“

“

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Ogaki, Kenichi <[email-masked]>
Date: Tuesday, September 14, 2021 at 9:52 PM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Luis and All,

Thanks,

Kenichi

Hi all,

Yes/Support.

[KO] Agree.

Best regards

Luis

All,

Thank you,
Pavan and Lou

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 17 Sep 2021 03:15:22 +0000

Hi Med and All,

Thanks for your comments.

Let me clarify [KO], please.

Thanks,
Kenichi

From: [email-masked] <[email-masked]>
Sent: Thursday, September 16, 2021 7:03 PM
To: 大垣 健一 <[email-masked]>; TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: RE: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Kenichi, all,

[KO] Agree.

[KO] Our objective is not mapping ietf network slice to VN. We understand that the *current* VN defined in actn-vn-yang is different from ietf network slice.

We don't want to compare ietf network slice with VN, but want to reuse the existing data model as the *NBI solution* with appropriate augmentations to avoid new CAPEX/OPEX.

If I'm wrong, correct me, non-supporters.

[KO] Agree. If I remember correctly, there was no discussion at that time. But, I think L3SM might be augmented for L2SM if the similar discussion had happened. If I'm wrong, Adrian and Qin correct me.

[KO] I have not been aware of this issue, but WG chairs should handle this?

Although I have never checked the patent claims and this is just a hypothesis, I'm concerning that this issue may affect the NBI model, since not a few people believe the NBI draft model can be covered by actn-vn-yang with augmentation.

Then, the NBI draft may also conflict with the patent if the scope of the claims is wider. Also, any ietf network slice NBI may not be able to handle the underlying TE network without conflicting, even if the scope is limited to ACTN or TE specific technology.

Anyway, this is another problem.

Thank you.

Cheers,
Med

[[snip>>

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 17 Sep 2021 21:07:43 +0530

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

[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 <[email-masked]>
wrote:

> On Fri, Aug 27, 2021 at 10:07 AM Vishnu Pavan Beeram <
> [email-masked]> wrote:
>
>> All,
>>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 20 Sep 2021 04:53:58 +0000

Hi Dhruv,

Thanks for your reply.

See comments inline [KO], please.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Teas <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
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.

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.

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!

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

[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;

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/

[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:

[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 <[email-masked]<mailto:[email-masked]>> wrote:
WG,

Regards,
Pavan and Lou

On Fri, Aug 27, 2021 at 10:07 AM Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:
All,

Thank you,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 28 Sep 2021 08:24:33 -0500

All,

The WG poll is closed. The document has been adopted (based on
discussion both on the list and the interim session).

Authors,

Please republish draft-wd-teas-ietf-network-slice-nbi-yang-04 as
draft-ietf-teas-ietf-network-slice-nbi-yang-00 with only the date and
file name changed. Please do NOT use -05 (that isn't the version
that was polled for adoption); the changes in -05 may be added in
a subsequent version.

Please note that any changes to the document post adoption MUST be
discussed on the list. Please continue the discussion for the open
items on the list - one thread per open question would be ideal.

Regards,
-Pavan and Lou