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

mohamed.boucadair@orange.com Thu, 16 September 2021 10:03 UTC

Return-Path: <mohamed.boucadair@orange.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 738473A22DE; Thu, 16 Sep 2021 03:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 cv6RZDComf3j; Thu, 16 Sep 2021 03:03:03 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197213A22DD; Thu, 16 Sep 2021 03:03:03 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4H9CM90MQ8z5wHF; Thu, 16 Sep 2021 12:03:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1631786581; bh=0T4O4u2/7FKSZUk1eldnPn9CuWJonsfF1/WP3C1Cux0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=DSRoP9u5l/QwBBv/tdD7Oe3oPVtZ+GUzrwQUxY0M0Pwio5LkIVW3as6g6gfeyjSQp 4ln4ZhXgd4nA8VGd+o8JfELB+YwuXVXZEj6y9b5Q1nvHJ6nTZHtoIeOlgX13ZO1nZf Yn82hMW+j78IQvnN7E4xCRtjKrL7gpnG1TU5OgxXoBIAXxptWRhR01MB/wBh7NdN5V cgUsMDyorvSIfPc12NjgN3C9pvJzZOARjBkUIg72Fhrxt1aXfw/DK6iaTQLPtcGwGv 2laLQlAOoH4nvquy/8Ibo414VxSv58VyzSkyJaSINRMlc/dpPBCsiIqu8qbRnWTQPR I6fJa4XvkvtnA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar04.francetelecom.fr (ESMTP service) with ESMTPS id 4H9CM86HV3z1xp0; Thu, 16 Sep 2021 12:03:00 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>, TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>
Thread-Topic: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04
Thread-Index: AQHXm1VP9rfBs1RnZEa73n2bfVmQj6uidHOAgAH3bVCAAhQVgA==
Date: Thu, 16 Sep 2021 10:02:59 +0000
Message-ID: <16226_1631786580_61431654_16226_357_2_787AE7BB302AE849A7480A190F8B9330354072F9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CA+YzgTvvwy=0Pstp79UNkjKF014Y=b96=uMMaDU35uLTAVj0Aw@mail.gmail.com> <DB9PR06MB7915B14E00F42874AF5C7A969ED99@DB9PR06MB7915.eurprd06.prod.outlook.com> <TY2PR01MB356257CA5431094F547D279590DB9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB356257CA5431094F547D279590DB9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330354072F9OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/sgiAgxTWhdONN2g9RR59378PDTs>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04
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, 16 Sep 2021 10:03:09 -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:teas-bounces@ietf.org] De la part de Ogaki, Kenichi
Envoyé : mercredi 15 septembre 2021 03:42
À : LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>om>; Vishnu Pavan Beeram <vishnupavan@gmail.com>om>; TEAS WG <teas@ietf.org>
Cc : TEAS WG Chairs <teas-chairs@ietf.org>
Objet : Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04


[[snip>>

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.


[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


_________________________________________________________________________________________________________________________

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.