Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10

Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 02 September 2021 07:14 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48143A107A; Thu, 2 Sep 2021 00:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mlWkTUxeSwN; Thu, 2 Sep 2021 00:14:42 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79ACB3A1034; Thu, 2 Sep 2021 00:14:41 -0700 (PDT)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4H0XFL03yxz67PnY; Thu, 2 Sep 2021 15:12:54 +0800 (CST)
Received: from blreml704-chm.china.huawei.com (10.20.5.34) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Thu, 2 Sep 2021 09:14:36 +0200
Received: from blreml706-chm.china.huawei.com (10.20.5.32) by blreml704-chm.china.huawei.com (10.20.5.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 2 Sep 2021 12:44:34 +0530
Received: from blreml706-chm.china.huawei.com ([10.20.5.32]) by blreml706-chm.china.huawei.com ([10.20.5.32]) with mapi id 15.01.2308.008; Thu, 2 Sep 2021 12:44:34 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>, Tarek Saad <tsaad.net@gmail.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>, Dhruv Dhody <dhruv.ietf@gmail.com>
Thread-Topic: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10
Thread-Index: AQHXm0H+qcQafDcqwEicHRYp9zAJVKuLwCvwgAMpjACAAA1KAIABTcFw
Date: Thu, 2 Sep 2021 07:14:34 +0000
Message-ID: <be8664737ea144a5b71340ad9baf7d5c@huawei.com>
References: <6f076887-1887-4e41-a48d-6c92b282c29c@AM5EUR02FT020.eop-EUR02.prod.protection.outlook.com> <AM8PR07MB82954D0C1EE5202964645F88F0CB9@AM8PR07MB8295.eurprd07.prod.outlook.com> <DM5PR1901MB2150EE8227FAC3DC1B42B7F2FCCD9@DM5PR1901MB2150.namprd19.prod.outlook.com> <AM8PR07MB8295E0A26BADCEE243C8D233F0CD9@AM8PR07MB8295.eurprd07.prod.outlook.com>
In-Reply-To: <AM8PR07MB8295E0A26BADCEE243C8D233F0CD9@AM8PR07MB8295.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.57.104]
Content-Type: multipart/alternative; boundary="_000_be8664737ea144a5b71340ad9baf7d5chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/0pnjDhIDcKuHnwsjUBvnbB80Gys>
Subject: Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2021 07:14:56 -0000

Hi Daniele,

My suggestion would be for the draft-king to use the term “realization of IETF network slice” to make it clear. From what I gather they do mean realization as they use the phrase “ACTN is a toolset capable of delivering network slice functionality.”; which is consistent with my understanding.
A possible relationship between draft-wd and that of ACTN is as per figure 6.

Section 4.1 provides how the existing ACTN YANG and LxSM models are enough to provide IETF network slice service for the underlying network supporting ACTN. I agree with that. But the scope of the IETF network slices was much broader and that is why WG worked on a new framework instead of extending the ACTN framework. The same applies to the YANG model.

Anyways. the authors did explore with the WG why augmenting the VN model was problematic because of the tight coupling with TE topology. Overall this is akin to having both technology-specific model (LxSM and VN) as well as technology agnostic intent model (and letting the consumer decide what make sense for them to use when both interfaces are available).

I will do a further review of draft-king to make sure things are consistent.

Thanks!
Dhruv

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 01 September 2021 20:50
To: Tarek Saad <tsaad.net@gmail.com>om>; Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>rg>; Vishnu Pavan Beeram <vishnupavan@gmail.com>om>; TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <teas-chairs@ietf.org>
Subject: Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10

Hi Tarek,

The coexistence of VN and LxSM/LxNM is something that no one is putting under discussion…even better…the TE service mapping model maps one against the other to bind a LxVPN against a TE infrastructure (TE tunnel or VN) and make the service inherit the capabilities of the TE infrastructure.

As of today I would build a network slice in the following way:
-          Create a LxVPN (using LxNM model)
-          Create a TE infra (using TE tunnel model or VN model)
-          Bind the LxVPN to the TE infra (using the TE service mapping model)

What is missing there? The capability to support non TE infrastructure. It’s something that could have been easily added to the VN model by augmentation.

What would I need to implement as an orchestrator vendor? Completely different models to create the same thing in the network?

Moreover I find it at least misleading the adoption of a draft saying how to use ACTN to create a slice and then in another draft have a completely different model to create a slice.
At least we should be coherent and say that ACTN is not needed for network slicing and the other model must be used (statement I disagree with but it’s up to the WG to decide).

Cheers,
Daniele

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Tarek Saad
Sent: den 1 september 2021 16:33
To: Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org<mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>>; Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>
Subject: Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10

Hi Daniele,

I do not dispute that ACTN VN can be possibly extended to allow provisioning of IETF slice service. 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).
Hence IMO, extending applicability of ACTN to network slicing does/should not negate having a IETF slice service specific data model.

   The VN model defined in this document is applicable in generic sense
   as an independent model in and of itself.  The VN model defined in
   this document can also work together with other customer service
   models such as L3SM [RFC8299<https://datatracker.ietf.org/doc/html/rfc8299>]9>], L2SM [RFC8466<https://datatracker.ietf.org/doc/html/rfc8466>] and L1CSM
   [I-D.ietf-ccamp-l1csm-yang<https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-12#ref-I-D.ietf-ccamp-l1csm-yang>] to provide a complete life-cycle service
   management and operations.

Regards,
Tarek

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org<mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>>
Date: Monday, August 30, 2021 at 4:59 AM
To: Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>, TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>
Subject: Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10
Hi WG,

while reviewing this draft and the network slice NBI YANG I find a major discrepancy between them.
While draft-king-teas-applicability-actn-slicing-10


  draft-wd-teas-ietf-network-slice-nbi-yang-04 says that:

“ACTN is a
   toolset capable of delivering network slice functionality.  This
   document outlines the application of ACTN and associated enabling
   technologies to provide network slicing in a network that utilizes
   IETF technologies such as IP, MPLS, or GMPLS.  It describes how the
   ACTN functional components can be used to support model-driven
   partitioning of resources into variable-sized bandwidth units to
   facilitate network sharing and virtualization.”

On the other side we have a network slicing NBI model completely detached from ACTN that says:


“The difference between the ACTN VN model and the IETF Network Slice

   NBI requirements is that the IETF Network Slice NBI is a technology-

   agnostic interface, whereas the VN model is bound to the IETF TE

   Topologies.  The realization of the IETF Network Slice does not

   necessarily require the slice network to support the TE technology.”



And



“However, the Network Slice SLO and Network Slice

   Endpoint are not clearly defined and there's no direct equivalent.”


So is ACTN applicable to network slicing or not? And if yes how? I was expecting to see the NBI model based on the ACTN models with some augmentation to cover the e.g. the non TE parts, the LSO and the endpoints…but we have two completely disjoint modules.
I would say that the two drafts are saying exactly the opposite thing, am I missing something?

Thanks,
Daniele


From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Vishnu Pavan Beeram
Sent: den 27 augusti 2021 14:49
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>
Subject: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10

All,

This is start of a *two* week poll on making
draft-king-teas-applicability-actn-slicing-10 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