Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

"Luis M. Contreras" <contreras.ietf@gmail.com> Tue, 23 February 2021 22:46 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 52EF93A0E3C for <teas@ietfa.amsl.com>; Tue, 23 Feb 2021 14:46:11 -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=unavailable 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 moY5VfY9y1Lw for <teas@ietfa.amsl.com>; Tue, 23 Feb 2021 14:46:08 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 92F0F3A0E3A for <teas@ietf.org>; Tue, 23 Feb 2021 14:46:08 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id 81so428769qkf.4 for <teas@ietf.org>; Tue, 23 Feb 2021 14:46:08 -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=O9G/6K73rtcl5cTChlQ748gbcQKvNcS0AgVcecW3a1o=; b=rtUBsfgw9SgyC6eSfQ4Lgkgask1Nzaap4zgGyAD3OV4AsEm5wKug5oZ3xtk3ngCBaw 2Raar8vfqtCsjCibMvJA94jR5fW3Y3yrRD35pgHxWi7rA01XNdt9QUKVRJwwWv5sK9RO 8PGlpnFB4MULcDgtfoNpYMpzWrhuYwytlI3T97OFamQLae/2dZkUPgTyPDWY0paiEEnh NJacixNtDegXzoBktq0EJChvveqUTKJA2YTm8hYXSNdbeoNPmcTRf/suw2Ht+jNjmT8s +z/2/wJVLsvy3Fwgplr77B1OYuCAyRagXL9sRGNeaDh+o5AVlOvswspo6C4uB7tpPSZZ PmQA==
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=O9G/6K73rtcl5cTChlQ748gbcQKvNcS0AgVcecW3a1o=; b=bPJmg0m8J1e2zhBDzZugeTuulrXa65IDK/w1z0dwC3+QUAGxP4eDOuJSNuDJfO0J5t DQRvXKA4ok32+xxN8k6hcJiwrfZoI2G6A6UK51e8zQje9Ev5qzab3uvK2CgFaSaA8UgR h2kG28uo6ajeL1ConAwj4ERjTN5llM8V9Rty183ctIsqCLX9r+YfvUVxIHoFBzQQFlY6 VvjM6jEOHMVZIkJkt6ERif6TaBf1h8xRXZtzkbwOeBRCpt+MNDOwqzTcTHpexIAsb0b2 fVeRFtol35os0DnEEhmPpPJFRnMIoje5nGPxn4tQFou4mhhRD/M09OozwgfQtIk/H3Wi BC4w==
X-Gm-Message-State: AOAM530pzoMIDNISRG7t1GKp2LTFsdkAGSHO6KtUGnDKGH5GKeVItN+X bDOu7I+1Rf7Pec33Qny+rfrJGA6OwR4zMn0D/WU=
X-Google-Smtp-Source: ABdhPJyJQPHSYkK/DuPYtJ7bqV0eApLiGk6zh2TRpIdVZNf7/Kv8Qe8aqxQUfNf/I3p9d37kjg9DoHaVDXRyJLSq1Pc=
X-Received: by 2002:a37:a085:: with SMTP id j127mr1641412qke.206.1614120367615; Tue, 23 Feb 2021 14:46:07 -0800 (PST)
MIME-Version: 1.0
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com> <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <cde51de3-4533-9acd-a654-59a1dc9f195b@joelhalpern.com> <11878_1613494720_602BF9C0_11878_194_1_787AE7BB302AE849A7480A190F8B9330315CF9FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <71F75531-DE7E-419E-890D-A5AB6D5F4D8F@nokia.com> <27179_1614103167_6035427F_27179_485_2_787AE7BB302AE849A7480A190F8B9330315D83ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <54DAE6D4-7435-4E1A-9538-51F2ED35B132@gmail.com>
In-Reply-To: <54DAE6D4-7435-4E1A-9538-51F2ED35B132@gmail.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Tue, 23 Feb 2021 23:45:55 +0100
Message-ID: <CAE4dcxnhjszy7OMD-JusSnDBg2oR7Buo4XKO6gXk1-DrQc2FsA@mail.gmail.com>
To: Eric Gray <ewgray2k@gmail.com>
Cc: mohamed.boucadair@orange.com, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="00000000000022f22e05bc08afde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ZWrBsR06pPUlRWSHJYt5LfwL7jA>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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: Tue, 23 Feb 2021 22:46:11 -0000

Hi all,

Regarding the CE / PE discussion, I have doubts if this would apply to
scenarios where we could have stitching of IETF Network Slices or in
scenarios where an IETF Network Slice of technology X is supported on  IETF
Network Slice of technology Y. While end-point can work in all the cases, I
think that CE / PE don't become naturally applicable in all cases.

Respect to the discussion on IETF Network Slice Service, I think it is
redundant since we are talking of consumer/customer and provider in the
context of  IETF Network Slice, so being "Service" redundant there.
Probably adds more confusion than clarification.

Best regards

Luis


El mar, 23 feb 2021 a las 20:20, Eric Gray (<ewgray2k@gmail.com>) escribió:

> Reza,
>
> Please see *in-line responses* below…
>
> Note: I am trying not to repeat responses already made.  If I respond to
> ay point with a similar response to ay already given, I apologize in
> advance...
>
> —
> Eric
>
> — [SNIP] ---
>
> *De :* Teas [mailto:teas-bounces@ietf.org <teas-bounces@ietf.org>] *De la
> part de* Rokui, Reza (Nokia - CA/Ottawa)
> *Envoyé :* mardi 23 février 2021 17:53
> *À :* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; BOUCADAIR
> Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>; Joel M. Halpern <
> jmh@joelhalpern.com>gt;; teas@ietf.org
> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
> *Objet :* Re: [Teas] network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00
>
> All,
>
> In summary I am in agreement for some parts.
> Please see a few comments inline.
>
> Reza
>
>
>
>
> On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <teas-bounces@ietf.org
> on behalf of jdrake=40juniper.net@dmarc.ietf.org> wrote:
>
>     Hi,
>
>     Eric and I have reviewed the Definitions draft, the email thread with
> the subject line: Network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced
> in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would
> like to propose that in the Definitions draft we replace 'network slice
> endpoint' with 'CE' and 'network slice realization endpoint' with 'PE',
> that we reference  RFCs  3985, 4110, 4026, 4664, and 8309,
>
> [Reza] The IETF network slice endpoints (NSE) can  be mapped to some
> virtual or physical interfaces on CE or PE depends on the use-case. But the
>  “IETF network slice endpoints” are not CE or PE nodes themselves.
>
>
> *CE and PE components are as capable of being virtual as any component
> currently included in the **draft - hence it might be a littler bit
> disingenuous to assume that the end points described in the draft cannot be
> part of a CER or PE, because these are “nodes” (implying physical devices).*
>
> *If we are defining ed points specifically
> to justify using new terminology, perhaps we could stop doing that? *
>
> We have added more explanation to
> *draft-wd-teas-ietf-network-slice-nbi-yang-02* figure 4 and 5. This is
> the summary.
>
>
> *It is awkward to have a terminology section, or a definition **draft,
> that refers to a modeling draft for explanation of the terms being defined.*
>
>
> “IETF network slice endpoints (NSE)” are logical entities which can be
> mapped to interfaces on CE or PE nodes depends on use-case. The following
> pictures show two use-cases where in one NSE are mapped to interface on PE
> nodes and in other one NSE are mapped to interface on CE nodes.
>
>               NSE1                                     NSE2
>        (With PE1 parameters)                       (with PE2 parameters)
>                o<--------- IETF Network Slice 1 ------->o
>                +     |                            |     +
>                +     |<----------- S1 ----------->|     +
>                +     |                            |     +
>                +     |    |<------ T1 ------>|    |     +
>                  +   v    v                  v    v   +
>                    + +----+                  +----+ +
>     +-----+    |     | PE1|==================| PE2|          +-----+
>     |     |----------X    |                  |    |     |    |     |
>     |     |    |     |    |                  |    X----------|     |
>     |     |----------X    |                  |    |     |    |     |
>     +-----+    |     |    |==================|    |     |    +-----+
>                AC    +----+                  +----+     AC
>     Customer         Provider                Provider        Customer
>     Edge 1           Edge 1                  Edge 2           Edge 2
>
>
>
>               NSE3                                     NSE4
>        (With CE1 parameters)                       (with CE2 parameters)
>                o<--------- IETF Network Slice 2 ------->o
>                +     |                            |     +
>                +     |<----------- S2 ----------->|     +
>                +     |                            |     +
>              +       |    |<------ T2 ------>|    |      +
>            +         v    v                  v    v        +
>          +     AC    +----+                  +----+          +
>     +-----+    |     | PE1|==================| PE2|          +-----+
>     |     |----------X    |                  |    |     |    |     |
>     |     |    |     |    |                  |    X----------|     |
>     |     |----------X    |                  |    |     |    |     |
>     +-----+    |     |    |==================|    |     |    +-----+
>                AC    +----+                  +----+     AC
>     Customer         Provider                Provider         Customer
>     Edge 1           Edge 1                  Edge 2           Edge 2
>
>
>   Legend:
>        O: Representation of the IETF network slice endpoints (NSE)
>        +: Mapping of NES to PE or CE nodes on IETF network
>        X: Physical interfaces used for realization of IETF network slice
>        S1: L0/L1/L2/L3 services used for realization of IETF network slice
>        T1: Tunnels used for realization of IETF network slice
>
>
> and that we  replace the current figure in Endpoint section with several
> figures, which show connectivity constructs and which are consistent with
> these RFCs.
> [Reza] It is fine. Please suggest a figure and it can be included in draft
>
> We would also like to replace 'consumer' with 'customer',
> [Reza] Fine
>
> add 'attachment circuit', and add a new term, viz, 'IETF Network Slice
> Service',
> [Reza] Why new term? This is what it is called “IETF Network Slice”.
>
>
> *This is not so much a new term as a clarification for the phrase “IETF
> Network Slice” when applied to a “service interface.**”*
>
> *In order to describe a interface generic enough to be applied in any
> technology **agnostic fashion, we should be defining
> a “service” interface (as is obvious from the choice to describe this
> in “service” terms - i.e. - “service level objectives”).*
>
> *If we use the phrase “IETF Network Slice Service,” it is clearer that we
> are referring to a “service-based” abstraction of any underlying “IETF
> Network Slice."*
>
>
> whose definition is a set of CEs, a set of connectivity constructs (MP2MP,
> P2MP, P2P, etc.) between subsets of these CEs and an SLO for each CE
> sending to each connectivity construct.
>
>     As an aside, the Endpoint section of the Definitions draft uses the
> bulk of its prose enumerating what its endpoints are not.  Per Yakov, since
> there are a potentially infinite number of things which its endpoints are
> not, this is futile and we would like to remove that prose.
> [Reza] which part of draft are you referring?
>
>
> *I had not thought this to be too subtle to be grasped by any observer
> that has been following the discussion on end point **definitions.*
>
> *The primary discussion in the draft is in section 4.2 (IETF Network Slice
> Endpoints).  *
>
> *However, the term “endpoint” appears quite often and is entirely unclear
> that there is more than one type of endpoint in almost all cases.  Hence,
> because we have defined these in a new way, it is as if we need to refer
> (at least) to section 4.2 each and every time we use the term - and clarify
> which type of endpoint we are actually using in each case.*
>
> *If we were clear that we are referring to “IETF Network Slice
> Service” endpoints, there is a more common term we could use to describe
> the relationship between the endpoints and the network components where
> they may occur.  A set of terms that are not only commonly used, but well
> understood in the industry.*
>
>
>     Yours Irrespectively,
>
>     Eric and John
>
>  — [SNIP] ---
>
> _______________________________________________
> 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