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

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

Hi Kenichi,

Thanks for your reply. Please see inline.

Regards,
Bo

-----邮件原件-----
发件人: Teas [mailto:[e-mail]] 代表 Ogaki, Kenichi
发送时间: 2021年9月3日 9:38
收件人: Wubo (lana) <[e-mail]>; Daniele Ceccarelli <daniele.ceccarelli=[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
抄送: TEAS WG Chairs <[e-mail]>
主题: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Bo,

Thanks for your prompt reply.

See comments [KO] inline, please.

Thanks,
Kenichi

-----Original Message-----
From: Wubo (lana) <[e-mail]>
Sent: Thursday, September 2, 2021 9:28 PM
To: 大垣 健一 <[e-mail]>; Daniele Ceccarelli <daniele.ceccarelli=[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Kenichi,

Regarding requirement3 2)-4), please see inline.

Thanks,
Bo

-----邮件原件-----
发件人: Teas [mailto:[e-mail]] 代表 Ogaki, Kenichi
发送时间: 2021年9月2日 16:00
收件人: Daniele Ceccarelli <daniele.ceccarelli=[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
抄送: TEAS WG Chairs <[e-mail]>
主题: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

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.
[Bo] The authors agree that peering control protocol on the slice demarcation point is technology-related, but after the discussion in the authors, in the draft rev-04, we suggest modeling as a list of "protocols" to address this and to be technology agnostic.

[KO] The NBI is customer - provider reference point. If the slice demarcation point is not clearly defined, then the NBI cannot be used in a real-life operation.
During L3SM definition, multiple L3VPN providers carefully discussed, reviewed and defined the model definition of the demarcation point, CE-PE connection.
From a commercial VPN service deployment/operation experience, the same level as L3SM's is necessary. We believe same for L1/L2 AC.

[Bo 2] Thanks for the suggestion. We'll add similar definition as LxSM.


>> >(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.
[Bo]: I'm not sure about this comment. Could you elaborate on this?

[KO] The current ns-connection definition is a set of src/dst pair. In my understanding, to easily express p2p, p2mp, mp2p, mp2mp connectivities, Sec. 3.2. of draft-ietf-teas-ietf-network-slices-04 introduced connectivity matrix based on the discussion in "[Teas] Proposed text on "IETF Network Slicing Service"" thread. I don't think a set of src/dst pair cannot express those connectivities, but it's definitely complicated and exhausted to specify an arbitrary connectivity for a customer.
[Bo 2] Thanks for detailed description.
    This connectivity matrix is a new concept, and the author believe more discussion with WG is needed. For example, the draft-ietf-teas-ietf-network-slices-04 defines the slice service connectivity matrix, but also defines slice connectivity types between Network Slice Endpoints (NSEs). 
    In our understanding, the slice service connectivity matrix is the traffic matrix of the slice service flow. 
   For the src/dst pair concern of "ns-connections", the authors also discussed and suggest to use "ns-connectivity-type" together with "endpoint-role" to indicate the well-known connectivity types, such as any-to-any, hub-spoke, etc.


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.
[Bo] The authors define the NBI model based on definition of draft-ietf-teas-ietf-network-slices-03. We can fix this in the next release.

[KO] As we wrote below, our concern is that the efforts to solve these requirements would have resulted in creating a copy of 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 <[e-mail]> On Behalf Of Daniele Ceccarelli
Sent: Tuesday, August 31, 2021 10:16 PM
To: Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
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 <[e-mail]> On Behalf Of Vishnu Pavan Beeram
Sent: den 27 augusti 2021 17:07
To: TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
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

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas