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

Young Lee <younglee.tx@gmail.com> Wed, 24 February 2021 10:27 UTC

Return-Path: <younglee.tx@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 B2DB83A135C for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 02:27:19 -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 KGVlOGqPZL0P for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 02:27:15 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 313CE3A135D for <teas@ietf.org>; Wed, 24 Feb 2021 02:27:15 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id r19so1694449otk.2 for <teas@ietf.org>; Wed, 24 Feb 2021 02:27:15 -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=EQBAiWldpemyNUNkY5vEAaOwQc1eizVrPkDR0042Yro=; b=fX+EmnLOBAzdkFwuo/9jAbRLJgQt0zv4pNDzMtGf1WQSvtU7MmA1U/0EQ/33COYtHW MlLzSWLitsDIOtL9DJ8bkLxsaRvsctltRVEJfPQqpiVADffyuNbQ/AiyVksGWT4oPeG7 PwaL06GpKoQcdG0/fzgUaX9ZtU9h2+ncez8a8/BjYS7vy/hgHa8XW5NJgVZe4jemOMY8 gcPWHzIxIOTfoK7ysOGSx1ACH4QIpJXp6sNa/e3RUqSvBjAbsUwKlHeEwYb9URUaZYou fLkJaLlgXDV7EzFCKq5wdif4DwljHZ0VVYSgBj5mweESei92ZYJgWvD96vIA6pY547GQ Yhwg==
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=EQBAiWldpemyNUNkY5vEAaOwQc1eizVrPkDR0042Yro=; b=PoyIdNAmpNbBV3A9qdQLWQMfsViGj1IVvNAKGaD8I3l+UopBkqDHEEIA6NwsGjwp3H QQlB6sB4GN6qeAJM+oYT8gMP3wK14guzpBF3K9j9TUiH+yaLiNc054/JHd1qX1e6WruC OVlrWv4zraNYFhmSCsXC1eSsY0UDVRS8PriS7kULSjJiNQfdH6S3WgUGEkRwrHEHCDIF gGJySBpLqRrGOa+W4bYZJuTOrJUDz7cCL0pNX+17bgWoEYSoWpXH6J8ZtBQ6F1I58TPF ZfnwynsFeO5Lk7Va+L60gWkhGkV69v7GU0yuV00nA4RSUeXykEhqtdo8LKaAG/wvZ+Co UD1Q==
X-Gm-Message-State: AOAM533mcDYNLwpcjqDw6P/q90lvssqAvOPlfC6vlNxNOdj80AMoDa42 apMernQKf81QmcOdjmWgvMKQsAknWpraJ+vKvW8=
X-Google-Smtp-Source: ABdhPJxnOwQF22kSKXS1c7OAQc6Iq2OfkBxfKr74rPY/0QY5sdPGCLNidM0R1CQuvLnZ7eeLPkhiV6YTss1yAoBvRjY=
X-Received: by 2002:a9d:4b99:: with SMTP id k25mr20058103otf.327.1614162434313; Wed, 24 Feb 2021 02:27:14 -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> <CAE4dcxnhjszy7OMD-JusSnDBg2oR7Buo4XKO6gXk1-DrQc2FsA@mail.gmail.com> <22018_1614147403_6035EF4B_22018_270_1_787AE7BB302AE849A7480A190F8B9330315D8A0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com> <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com>
In-Reply-To: <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com>
From: Young Lee <younglee.tx@gmail.com>
Date: Wed, 24 Feb 2021 19:27:01 +0900
Message-ID: <CAGHSPWO_Lk26ZOP2KsDPwrD24Q10+W2xK4tatNyJrsq8R7fe4Q@mail.gmail.com>
To: "Luis M. Contreras" <contreras.ietf@gmail.com>
Cc: mohamed.boucadair@orange.com, Eric Gray <ewgray2k@gmail.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="00000000000081d1f005bc127af7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Lyzi6axqp4-4hXGqo9p7Gza_Nao>
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: Wed, 24 Feb 2021 10:27:20 -0000

Sorry. I meant DC networks that host "core network functions".

2021년 2월 24일 (수) 오후 7:22, Young Lee <younglee.tx@gmail.com>님이 작성:

> Hi,
>
> This is an interesting discussion. I am now in the mobile side and
> reconginize that there are a number of scenarios that may need transport
> network slices (which is now called IETF network slices). For instance,
> possibly slices may be needed in the fronthaul, midhaul and backhaul as
> well as within DC networks that host the functions. Other than backhaul
> networks, the terms CE and PE may not be adequate because for the
> aforementioned transport networks except the backhaul, CE and PE
> terminology would not easily apply. For each of the aforementioned
> transport subnetworks, I think using slice endpoints makes more sense.
>
> In other words, I agree with Luis on this point.
>
> My two cents,
> Young
>
>
> 2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <contreras.ietf@gmail.com>님이
> 작성:
>
>> Thanks Med and Joel for the answers.
>>
>> Noting what you said, and assuming that we are covering not only IP/MPLS
>> technologies, probably we need to associate the same idea of CE and PE to
>> technologies where those roles are not commonly associated, such as OTN,
>> DWDM or wireless / microwave, since all of them can be potential targets of
>> the IETF Network Slicing realization. Then, if we follow this same
>> rationale and finally the WG decides to go in this direction, I guess we
>> need to span the CE and PE conception also to those, maybe explaining this
>> in the definitions draft. Am I right?
>>
>> Med, when I was referring to IETF Network Slice of technology X or Y I
>> was thinking on the realization. So my point here is that in case you have
>> an IETF Network Slice let's say realized as IP/MPLS, and another one let's
>> say realized on OTN or DWDM, where the IP/MPLS slice is supported by the
>> OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is
>> OTN/DWDM? It sounds strange to me.
>>
>> Best regards
>>
>> Luis
>>
>>
>> El mié, 24 feb 2021 a las 7:16, <mohamed.boucadair@orange.com> escribió:
>>
>>> Hi Luis,
>>>
>>>
>>>
>>> Actually, this is all about recursion, service decomposition and
>>> manipulating customer/provider ROLES. In all cases, there are reference
>>> points delimiting the scope of the slice from both the customer view (we
>>> call them, customer edges) and provider view (provider edges).
>>>
>>>
>>>
>>> Nothing prevents that at the realization stage, two PEs can’t be
>>> connected. I’m thinking about the example where inter-AS VPN can be used to
>>> implement an IETF network slice.
>>>
>>>
>>>
>>> BTW, can you please clarify what do you mean by a “IETF Network Slice
>>> of technology X or Y” as slice is technology-agnostic? Thank you.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> *De :* Luis M. Contreras [mailto:contreras.ietf@gmail.com]
>>> *Envoyé :* mardi 23 février 2021 23:46
>>> *À :* Eric Gray <ewgray2k@gmail.com>
>>> *Cc :* BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>; Rokui,
>>> Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>om>; John E Drake <jdrake=
>>> 40juniper.net@dmarc.ietf.org>gt;; teas@ietf.org; Joel M. Halpern <
>>> jmh@joelhalpern.com>
>>> *Objet :* Re: [Teas] network Slice Endpoint in
>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>
>>>
>>>
>>> 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
>>> <teas-bounces@ietf.org%20on%20behalf%20of%20jdrake=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
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> 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.
>>>
>>>
>>
>> --
>> ___________________________________________
>> Luis M. Contreras
>> contreras.ietf@gmail.com
>> luismiguel.contrerasmurillo@telefonica.com
>> Global CTIO unit / Telefonica
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>