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

["Ogaki, Kenichi" <[e-mail]>]

Hi Bo,

Thanks for your reply.

I merged your reply to Sergio, and commented inline[KO3].

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Wubo (lana) <[e-mail]>
Sent: Thursday, September 23, 2021 11:35 AM
To: 大垣 健一; Belotti, Sergio (Nokia - IT/Vimercate)
Cc: Dhruv Dhody; TEAS WG
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Kenichi,

Thanks for your reply. See inline please.

Regards,
Bo

发件人: Teas [mailto:[e-mail]] 代表 Ogaki, Kenichi
发送时间: 2021年9月22日 21:34
收件人: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; Wubo (lana) <[e-mail]>
抄送: Dhruv Dhody <[e-mail]>; TEAS WG <[e-mail]>
主题: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Bo,

Although Sergio already replied, let me complement inline [KO], please.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 22, 2021 7:49 PM
To: Wubo (lana)
Cc: TEAS WG; Dhruv Dhody; 大垣 健一
Subject: RE: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Bo,
See in line

Thanks
Sergio

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Wubo (lana)
Sent: Wednesday, September 22, 2021 9:58 AM
To: Ogaki, Kenichi <[e-mail]<mailto:[e-mail]>>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

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]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[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,



[KO] No, in my understanding, AP/TP is independent of IETF topology (model). AP/TP expresses the AC between CE and PE, but the topology we are talking in this thread is that between PE and PE, for example.

[Bo]  I agree with the statement that  AP/TP expresses the AC between CE and PE, but the topology I meant is the access link of the PE, not taking about the topology between PE an PE.


[KO3] From the AP/TP/NSE viewpoint, the access link, i.e. AC, doesn't have IETF topology model. We believe how to control AC, i.e. CE-PE, topology is out of scope even in ietf network slice. In almost of all cases, the operator cannot dynamically change an AC topology based on SLO/SLE requests.



 so are one-to-one relationship to ACs,



[KO] What do you mean "one-to-one relationship to ACs"?

[Bo] See above please.





and one or multiple APs may be assigned at the same customer demarcation point for protection purpose.



[KO] No, multiple APs are multiple demarcation points as defined in Sec. 6 of RFC8453.



[Bo] Here  is the difference between an NSE(Network Slice Endpoint) and an AP. The NSE does not distinguish between individual access links, but can treat multiple AP/TP/access-links as a whole.


[KO3] I have a different opinion. Sec. 4.2. of draft-ietf-teas-ietf-network-slices-04 defines that an NSE is a ingress/egress point and mapped to a device, for example. How can a slice service provider identify the ingress/egress point where two access links, i.e. ACs, exist between the customer and the provider? That information should be exchanged on the NBI.




And VNAPs refer to LTPs of PEs. VN uses the connection matrix between APs to describe the service topology of a VN.



[KO] No, connection matrix is defined among VNAPs, not APs. See /virtual-network/vn/vn-member.

[Bo]  Thanks for clarification.





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



[KO] No, customer doesn't necessarily specify the detailed topology among VNAPs if they don't want.

See Sec. 4.2. and 4.3.1.

[Bo] What I see is when the AP/access-link changes, the VNAP changes accordingly, and therefore the connection matrix between VNAP changes. Still, I was not talking about the topology between PE an PE.

For example, Dual-Homing Scenario in rfc8453#section-6.1, customer needs to know AP1, AP2, if AP2  is added to a VN, the VN-members of AP2-AP3 and AP3-AP2 need to be added to the connection matrix.

The NSE can take multiple APs/access-links as a whole. The slice connection matrix remains unchanged no matter one or several APs/access-links.



[KO3] Same as above. I believe that is not NSE definition, but one of possible solution implementations.



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.

[Belotti, Sergio (Nokia - IT/Vimercate)] Your reading is in fact not correct: The access point has been defined exactly with the purpose to create a logical identifier shared between customer and provider to permit the customer to ask for the VN, but both customer and provider need to map AP against their own physical resources e.g. CE for customer and PE (LTP) for provider. Similar concept exist in other forum to represent the same concept e.g. SEP in ONF. So, VN model does not require at all the customer to know detailed topology information, no difference with respect what you’re saying for NS service.



[Bo] Thanks for your clarification. I agree AP is a logical identifier but it maps to a access link between customer node and provider node. Any change in access link will cause the connectivity matrix of the VN change too. But the connectivity matrix between NSE is independent of access link change.


[KO3] I believe the last two sentences must be the same behavior. From the definition of NSE, Sec. 4.2. of draft-ietf-teas-ietf-network-slices-04, NSE(s) must be mapped to an access link, i.e. AC. When a customer wants to change an ingress/egress point, i.e. an access link, then NSE as well as connectivity matrix must be changed.

It's possible to remap the changed access link to NSE without the change of NSE ID, but the underlying topology must change, since the physical ingress/egress point changes.

Also, from an operator viewpoint, we want to avoid this, since this brings a complicated operation and a system implementation to remap. Then, NSE (ID) should be also physically unique.


Sec. 4.2. of draft-ietf-teas-ietf-network-slices-04

o The IETF NSEs are conceptual points of connection to IETF network slice. As such, they serve as the IETF Network Slice ingress/egress points.


o Each endpoint could map to a device, application or a network function. A non-exhaustive list of devices, applications or network functions might include but not limited to: routers, switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.


o An NSE should be identified by a unique ID in the context of an IETF Network Slice customer.


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