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

Tarek Saad <tsaad.net@gmail.com> Thu, 16 September 2021 14:16 UTC

Return-Path: <tsaad.net@gmail.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 5F76B3A2A91; Thu, 16 Sep 2021 07:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 0jvAx1-uJzux; Thu, 16 Sep 2021 07:16:01 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 CB9E33A2A8E; Thu, 16 Sep 2021 07:16:00 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id ay33so7459070qkb.10; Thu, 16 Sep 2021 07:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=IlU3/pG8E/1MQrcg20Cpy+cUAnMZ8LL9SrmDm61IF64=; b=KhLKdSuLEMTmj5Zw0L05z9AUpfDqn+3dGlxbC41GTY36JWGARAddKTvEejHNFye2Iq BAi9h0oxnuAuN4Xr4yRU+SX/lupTq/GvMgrM27KTBDKCbA3WJLlqlCV/nS+401H52jor F/zb3wiJ3VxUuXsjr6mEscG3DP0JydJFopt/GEv4RsEwo77wFo7dNryGYuYCjHC+EqrJ 2aCI9EHybzS6i0EqVUh1YnFo+qkk5uNNmzzL+sXa/SAEEGzRr8fQddX9PXAr8a6F7lo8 6SiInVN6bGs+XwMpZX2nEq6Wk2cid9SsOjBtCuAKCslpwS7wB//Gdfu1y7HtLZ+9t2+c wx4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=IlU3/pG8E/1MQrcg20Cpy+cUAnMZ8LL9SrmDm61IF64=; b=ZlqfRoRC7U5AVmfOqXqIUPYzTqL4NHaKGnwVNEA1V4v8cfRZHij/1hGjddHR5HXINA Yw6UVljvwh4qWIruHvxrxvjc0Xh/pZCAklvByOZAL4m26rXVD+wZA9DAmIlucyH5N2Jz Bht+xCHvPesb6xzF4B8n5rpLr+fG7HCYHidjIB17d1L98wtk1PWbm6NjUpcLtsoJtht4 hN6lsbwChrMupPF6BWD3P9hFFBPVTwlNszV0LLBXYjSSX5ZidDzrLjR+XUx+nXHxBIZr LpuulOUax8ggt4ikHnavz1B9xQo66Cq/N0cpGM9oWmPNnGwpTHjheT7QK4Cy3y3klZrO 4U4g==
X-Gm-Message-State: AOAM533Fmz23bl81hDpMagHSuOcZ5dzLOrNFf/1YfTn3HW4Y6BdxbFch MKwqiX6AFw08EA3lUtXtJHCAzfjHdgY7+w==
X-Google-Smtp-Source: ABdhPJzRkTcIWRRjxpSJSh4kbf6lzfdG4cGlEOpHcYwOhllteMx8OKp1zgneNJR1MSk1tcTUt9W8ZA==
X-Received: by 2002:a37:a391:: with SMTP id m139mr2040465qke.186.1631801757786; Thu, 16 Sep 2021 07:15:57 -0700 (PDT)
Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id i27sm2400735qkl.111.2021.09.16.07.15.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Sep 2021 07:15:57 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, Vishnu Pavan Beeram <vishnupavan@gmail.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: AXczYk55LxcOStH1KLlZLMNMEla6RMDq5oCAgAH6nACAAmG6Fg==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 16 Sep 2021 14:15:56 +0000
Message-ID: <DM5PR1901MB2150A4BD438C5D18990E2F48FCDC9@DM5PR1901MB2150.namprd19.prod.outlook.com>
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: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB2150A4BD438C5D18990E2F48FCDC9DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/gdf7wTKSWoS2oTCHTYcyP5WHNK8>
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 14:16:09 -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.

“

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
“

Regards,
Tarek

From: Teas <teas-bounces@ietf.org> on behalf of Ogaki, Kenichi <ke-oogaki@kddi.com>
Date: Tuesday, September 14, 2021 at 9:52 PM
To: 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>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

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 <teas-bounces@ietf.org> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, September 14, 2021 4:29 AM
To: 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-wd-teas-ietf-network-slice-nbi-yang-04

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.


[KO] Agree.

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

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.


[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

De: Teas <teas-bounces@ietf.org> En nombre de Vishnu Pavan Beeram
Enviado el: viernes, 27 de agosto de 2021 17:07
Para: TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>
Asunto: [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

________________________________

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