Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

"Luis M. Contreras" <contreras.ietf@gmail.com> Thu, 04 February 2021 19:41 UTC

Return-Path: <contreras.ietf@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 3D1093A177A; Thu, 4 Feb 2021 11:41:14 -0800 (PST)
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 GrgkRYGHPNeN; Thu, 4 Feb 2021 11:41:12 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 237A53A1779; Thu, 4 Feb 2021 11:41:11 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id u20so4545240qku.7; Thu, 04 Feb 2021 11:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hf+mnD5QJ1LS2JFsy2ekQfOKzBMKCRaaeJ+Six26iVU=; b=RGjGeFekCV+wUMgF2G+KjM700dT00ispNvHF9TXQ9KkYyeV6prbvNuyAUXWXRnoKX+ iutCa/eBMy8q3TY1P3ozRoAMdwyxtYIAwhPV5rc6vRS3Yt1k9V9rhibajSksbKmz7muD MtGa1uvfQokMyJMoMUlfXhB7sFS4/nsN9FWnAdCa4gM4EGbhOhvXZ6J4VwzFpc+WXj81 QpfdCpUECjsCAuZaMwhPAXmi36o/+qI/ITb4PagMtrB7Ixmyjgs//CihO2hUnKpHfBI3 vqkktnOAFJN43ogvwWcssv28YSxSDZ0ZxrnxuvPAFSHTWORP9ku5qbGmytmIgnHvQi1w 63Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hf+mnD5QJ1LS2JFsy2ekQfOKzBMKCRaaeJ+Six26iVU=; b=mXqxHblsQSgbPbNqBk3A1jb+MgLA6NC8VdACDQI2SKZKyHq3ZxoFwUMd0E0nrnKBpS Y7EYrc9SF8UA6Wbwgc4d1PXbZ0fgGQ8t3xdDS6RZh3YL6BI4g0hM/5olGtFszmr5OPq9 +XYW33KG/eyV6QgxjwVVhHhZ9vFse5PLdZH9JpN7ulfponSAsD6mFWZg75ndrcyyUbKV wWbElVcGhESoW0ac2/a8kYJ7iXaWDluJUHn6ijiS+6Y/ijyrx7kfZUFNmrqz+m8YAPf7 5hSvwdxzOVOqHH9TCAva4qDSvep3diTdCTsrF6DApj0MbgpzcZxKu93/NezGtKmPjWbT kGcg==
X-Gm-Message-State: AOAM533fr2hG+ZJJFAGAoi3Q6oLAviRApXoDvWMxlseIFNZ2xw4Q2r4W rmBVNtSFVKhh9vhGdkdYHTcMGy986Eci/FY3zJ+8cbOR1HQ=
X-Google-Smtp-Source: ABdhPJz09IAvPe4eiG8i4FoB3OuzHp1BefaKBDUH8ecO7iPfAR0NFOgaBvsHLNxNQ+AqUEUDLvdRjEfP211Ey1cDjOg=
X-Received: by 2002:a37:5d5:: with SMTP id 204mr801251qkf.436.1612467671089; Thu, 04 Feb 2021 11:41:11 -0800 (PST)
MIME-Version: 1.0
References: <CA+YzgTvbSffUFcdgZ97k+TL720LvH+NT8k2zBVB6bocZPYDgQA@mail.gmail.com>
In-Reply-To: <CA+YzgTvbSffUFcdgZ97k+TL720LvH+NT8k2zBVB6bocZPYDgQA@mail.gmail.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Thu, 4 Feb 2021 20:40:59 +0100
Message-ID: <CAE4dcxmnrXgFs2c9krBD6fH2YzxQ1OB5gr94zmT+DZxMFu=iMw@mail.gmail.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Cc: TEAS WG <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bf440c05ba87e2eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9t5Cp59yphgRx9N87AsioThsRlI>
Subject: Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05
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, 04 Feb 2021 19:41:14 -0000

Hi all,

Despite the fact that I acknowledge the value of the document, I feel more
discussion is needed before adoption. So I don't support the adoption at
this stage. Essentially,

Some reasons for that are:

.- The document states in sec. 3.2 that the NSC from one operator could
request IETF network slices to the NSC of another operator. This has
several implications in the NSC, and as such, should require more
discussion. For instance: (1) there could be different levels of
trustiness in the relationship among operators tat could imply different
levels of abstractions, not necessarily the same as with another kind of
customer/user, then open the door to the support of different kind of
information to be supported by the NBI; (2) the relationship between
operators could come via higher level systems instead, then relaxing /
modifying considerations such security, monitoring information, etc; (3)
having a direct relationship implies that one of the the SBI
implementations of a NSC should the same as the NBI, to support this
possibility; (4) there should be a common understanding / definition of the
abstractions between operators to express the services; etc

.- The document has a specific section for ACTN (sect. 4). In fact there
was some discussion on the list about this, reflecting the fact that
several interpretations could be provided for a mapping as the intended in
Figure 1, without a single mapping of entities between ACTN and the
intended framework. Besides that, a specific document describing the
applicability of ACTN to slicing
(draft-king-teas-applicability-actn-slicing) is now work-in-progress,
making the ACTN text in the framework document redundant with that other
document. In my view, sect. 4 is more confusing than clarifying, so I
prefer to remove it from the framework document, developing the
applicability of ACTN to slicing in that other dedicated document.

.- Section 3.5 described an initial workflow on the realization of IETF
Network Slices but it focuses only on provision. Other aspects of the IETF
Network SLice lifecycle are missing, and I think it would be important to
describe since this framework will become the basis for further
specifications of functionality of the IETF NSC. For instance, capability
exposure of the NSC (what happens if some SLOs cannot be provided?),
fulfillment, assurance, etc, are not included/discussed.

This is not an exhaustive review, this is just to remark the need of more
discussion for having clear the perimeter of the document before
progressing it into adoption, from my point of view.

Best regards

Luis


El jue, 4 feb 2021 a las 14:43, Vishnu Pavan Beeram (<vishnupavan@gmail.com>)
escribió:

> All,
>
> This is start of a *two* week poll on making
> draft-nsdt-teas-ns-framework-05 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 February 18th.
>
> Thank you,
> Pavan and Lou
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica