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

Shunsuke Homma <shunsuke.homma.ietf@gmail.com> Sat, 27 February 2021 07:01 UTC

Return-Path: <shunsuke.homma.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 1C2F33A1323 for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 23:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.087 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 pOngFum4YP-p for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 23:01:08 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 5478B3A1320 for <teas@ietf.org>; Fri, 26 Feb 2021 23:01:08 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id e2so6031142ljo.7 for <teas@ietf.org>; Fri, 26 Feb 2021 23:01: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=RGjuNcTYdozvMQ3uDerNg2wc4tqP+3I3U1WsT6g390A=; b=YEHMKicjR6YK0ri00xUe4pD9h18HrCxRAuUZdFAwwshwPtR8s0pJEjyO61AsNiyvqA J79DM2RD9QidP4rnmykaUHV2J4TC4RlJ8z85ZnwDri1ncgcFNpWw1+GsALsiAPCHykHO Ne2pIkdAdOOPtTqrKkli3nMvenCm1YP7I/BRwZZiQiiVDDA6Ts5gLIEsDQU1gwy6zWb0 ow687dKYLbCNghlWnEEpkazqG472W+DYKk31X7jIuwVxxGOcNcHqTPbG8cFlaUlWvI7H uHpRcICbgsWjXpGL52S6aAQGp5O/eXHhGK+jhDiszvVbiH6J3gPm8wh13anVStbui4aF dkIg==
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=RGjuNcTYdozvMQ3uDerNg2wc4tqP+3I3U1WsT6g390A=; b=F9gBGAH8PJQWHirhe/uf4xXXaN0KS0wnanmUIn8gxX1cMAoumnf5KPMCySouEZnVHr TPO11h1RJf30ZM081hzVOE1J15+iOD1QorsOzKbbjVlt2fB3uqFtVh+ODc0iozWtRReS JSMXEMtMiPuVMwSnkuAotp2ZhwCCo+hMp+NX4rm/k4ufM93eiJZmizoVe5qnSHrjck3D 15pmhcloosKPNHNpnAzLwe5vzcaa0LakoCR74eN4OUd9f4NoCsClr8oy3wzwhX6ZPnff w1lRotUvkvIAZR/WNpg4ZU86+JZRs2NyCcuuNKXmuMhTNPRalUgu5xaJmnReJ+v3I3l8 a8WQ==
X-Gm-Message-State: AOAM533ACHFD1Oa7ItlXpWeAi6RPj7CUlMq1lkSYWnbvf/PXEHpNsjFi KmV5CPDqELgRti8OGZtpHVYE6DNsC0Qp1KTqwSo=
X-Google-Smtp-Source: ABdhPJzQYBfV+mvhyCQve4VKFC7Jd8z3ZYF8T6ZSPqcZzNaqctFt5N0TDKShasb00wejiK/uEGWVIdowEFSeV6C/8y4=
X-Received: by 2002:a05:651c:555:: with SMTP id q21mr3595016ljp.471.1614409266195; Fri, 26 Feb 2021 23:01:06 -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> <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com> <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com> <069101d70b64$3d32bf10$b7983d30$@olddog.co.uk> <81cdb36e29e64fd79bafeb578926e6a8@huawei.com> <CABNhwV2ZVT47m17KARJDjXzr232bs5srp2KdD7njmgTPw0=8BQ@mail.gmail.com> <CAKr2Fb9cd6F7GGq7Pw-jPpxzwQtTE7M_DY0oQ83mmENoEHkTFw@mail.gmail.com> <CABNhwV3Dz86VkePniMGmF6vOvu63VEN9J-izHZ__=qn97cqzdg@mail.gmail.com>
In-Reply-To: <CABNhwV3Dz86VkePniMGmF6vOvu63VEN9J-izHZ__=qn97cqzdg@mail.gmail.com>
From: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Date: Sat, 27 Feb 2021 16:00:54 +0900
Message-ID: <CAKr2Fb9f9B-BUobJGV2X90tCUdAtHzoZHWth4nbqKG9cN3r1Gg@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Eric Gray <ewgray2k@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "Luis M. Contreras" <contreras.ietf@gmail.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Young Lee <younglee.tx@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d570a005bc4bf23f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/L0HbW0dOJCNSmYYfY9HCG5fwG8A>
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: Sat, 27 Feb 2021 07:01:13 -0000

Thanks, Joel and Gyan.

Yes, I agree that SFC classifier or tunnel endpoint can be a PE router.
Meanwhile, I assume there are cases that CF/VNE runs on non-PE/CE router.
For example, in case that SFC is performed within the provider's DC (e.g.,
5G DN), the ingress GW or ToR switch will be a classifier. Then, the GW/ToR
can be called CE or PE?

Certainly, in MPLS world, MPLS termination point is conventionally called
PE, but I feel PE/CE may not be generally used in DC or any other field.
Actually, Geneve termination point is called tunnel endpoint, and VxLAN
also use VTEP (VxLAN Tunnel End Point), not CE/PE. (Sorry if my
understanding is incorrect...)

If PE/CE are conceptual entities and can be applied to any cases, not only
MPLS(SR) networks, I assume that NSE and PE/CE are the same. Whichever is
fine to me.

Regards,

Shunsuke



On Sat, Feb 27, 2021 at 3:21 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> I agree that the PE / CE nomenclature can be used for any scenario where
> their is a customer handoff “demarcation” and only in those cases can apply
> the network slicing endpoint concept.
>
> Access - wireline/wireless
> Wireline
> MPLS/SR core VPN overlay - typical PE-CE demark
>
> MPLS/SR inter-as provider handoffs
>
> Wireless - RAN xHaul - 3GPP gateway to UE - fixed or mobile wireless 4G/5G
> -  UE to Gateway is the handoff point
>
> OTN-
> OTN GMPLS/MPLS-TP packet core - typically that is the operators
> infrastructure and so no customer handoff.
>
> Data Center-
> Data Center - typically no customer handoff
> Typical DC flavors -
> CLOS architecture BGP only DC
> NVO3 - leaf/spine - vxlan/nvgre/geneve
>
> Cloud - IAAS infrastructure as a service so no handoff
>
> Content provider- no handoff
>
> Web or content hosting - also no handoff paid for service offering
>
> So in summary the only two scenarios where you have a customer handoff is
> the operator access layer wireline and wireless above.
>
> So I think the PE / CE nomenclature fits the bill even with the network
> slicing paradigm shift.
>
> Kind Regards
>
> Gyan
>
> On Fri, Feb 26, 2021 at 11:59 PM Shunsuke Homma <
> shunsuke.homma.ietf@gmail.com> wrote:
>
>> I'm wondering if CE/PE can cover all cases.
>>
>> For example, can SFC CF/SFF (ref. RFC 7665) or Geneve tunnel endpoint/NVE
>> (ref. RFC8926)  put the internal of a provider network be an endpoint of
>> IETF network slice? And if so, can we call them CE or PE?
>>
>> Regards,
>>
>> Shunsuke
>>
>> On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <hayabusagsm@gmail.com>
>> wrote:
>>
>>>
>>> This is an interesting discussion.
>>>
>>> I understand their is a paradigm shift with Enhanced VPN  network
>>> slicing framework, however I think as John and Eric stated and I agree with
>>> their proposed update that “CE” replace “Network slice endpoint” and PE
>>> replace “Network Slice Realization Endpoint”.
>>>
>>> From an industry  perspective from an operators point of view,  I can
>>> see that maybe the Network slicing paradigm shift is being driven by 5G
>>> which has its key constructs of XHaul front back and mid haul vRAN and the
>>> mobile handset UE 3GPP user data plane and how much the CE is now aware of
>>> the underlay.
>>>
>>> As Adrian pointed out the CE based VPN versus PE based VPNs and the
>>> trade off for operators with CE based VPNs and how much knowledge are
>>> operators willing to give their customers about the underlay.
>>>
>>> As we all know that even though 5G is the industry driver of network
>>> slicing, the framework of network slicing as far as degree of isolation and
>>> steering is all based on the very overlay VPN concept now enhanced VPN+ to
>>> provide an improved user or SLA experience.   So the concept of network
>>> slicing  underpinned of overlay VPN with underlay resources and steering
>>> can be used for any use case with requirements of a higher grade SLA and
>>> not just 5G , such as DETNET or any content provider video streaming
>>> service offering or any service requiring a higher degree of isolation.
>>>
>>> Their are definitely trade off from an economics and value added service
>>> and ROI perspective  for CE versus PE based VPNs.
>>>
>>> Another point noted in this thread which I think is important and that
>>> is “confusion” related to changing the historical PE / CE terminology.
>>>
>>> That being said I do agree with John and Eric on their proposed change.
>>>
>>>
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>>
>>> On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <jie.dong@huawei.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Indeed good discussion about the terms, and thanks to Adrian for the
>>>> explanation and summary of the PE-based and CE-based VPNs.
>>>>
>>>>
>>>>
>>>> In the two figures provided in [1], the realization of IETF network
>>>> slice in both the service layer and the tunnel layer are the same, the only
>>>> difference is the position the NSE represents.
>>>>
>>>>
>>>>
>>>> Thus I also support the proposal of using the well-known terms CE/PE to
>>>> describe the endpoints of IETF network slice.  This could help to reduce
>>>> the possible confusions caused by using one term to represent different
>>>> positions. This could also help to understand the mapping from IETF network
>>>> slice requirements to its realization, which could be based on the
>>>> architecture and technologies described in the enhanced VPN draft [3].
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Jie
>>>>
>>>>
>>>>
>>>> *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Adrian
>>>> Farrel
>>>> *Sent:* Thursday, February 25, 2021 6:52 PM
>>>> *To:* 'Young Lee' <younglee.tx@gmail.com>om>; 'Luis M. Contreras' <
>>>> contreras.ietf@gmail.com>
>>>> *Cc:* 'Joel M. Halpern' <jmh@joelhalpern.com>om>; teas@ietf.org; 'Eric
>>>> Gray' <ewgray2k@gmail.com>om>; 'John E Drake' <jdrake=
>>>> 40juniper.net@dmarc.ietf.org>gt;; 'Rokui, Reza (Nokia - CA/Ottawa)' <
>>>> reza.rokui@nokia.com>gt;; mohamed.boucadair@orange.com
>>>> *Subject:* Re: [Teas] network Slice Endpoint in
>>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Good thread, and really good to see the debate on the WG list.
>>>>
>>>>
>>>>
>>>> I’m piling in in response to Young, mainly because that’s the email I
>>>> happen to have open. But also because the perspective of Young and Luis
>>>> should be valuable to us in this context.
>>>>
>>>>
>>>>
>>>> While I think that the usage of “CE” and “PE” has a long history in
>>>> packet networks, I don’t believe the concepts are firmly linked only to
>>>> packet. They are pretty much what they call themselves: the PE is at the
>>>> edge of the “provider” == “underlay” network, and the CE is at the edge of
>>>> the “consumer” == “overlay” network.
>>>>
>>>>
>>>>
>>>> I find that, as the discussion continues, we are still missing a really
>>>> clear figure to help us talk about what we are describing. But Reza’s [1]
>>>> is a much better start than anything previous. Here I see the classic
>>>> distinction between a CE-based VPN and a PE-based VPN [2], but we have to
>>>> ask ourselves carefully whether we **really** want the CE-based
>>>> approach in our network slicing:
>>>>
>>>> -          What are the considerations for how much knowledge of the
>>>> underlay network has to be shared to the CE?
>>>>
>>>> -          What are the considerations for how an underlay
>>>> distinguishes CE-originated slicing traffic?
>>>>
>>>> These are pretty much the same questions that CE-based VPNs have to
>>>> answer. Of course, the concept of a “provider-managed CE” muddies these
>>>> waters somewhat.
>>>>
>>>>
>>>>
>>>> Conversely, the port-based PE-based VPN has none of these problems, but
>>>> does have to agree on the “Access Connection” encoding, and that is either
>>>> payload-sensitive (like in PWE3) or technology-aware (like in L3VPN).
>>>>
>>>>
>>>>
>>>> But my opinion of all of this is coloured by thinking about enhanced
>>>> VPNs (VPN+) [3] and IETF network slices as the same thing.
>>>>
>>>>
>>>>
>>>> I also think that Luis’ point about contiguous or stitched segments is
>>>> important. There are, I think, two cases to be considered:
>>>>
>>>>    1. The multi-domain IETF network slice. Here the problem is very
>>>>    much the same as the multi-AS L3VPN. We have to consider how the “service
>>>>    request” is mapped from one domain to another. But it may help to recall
>>>>    that, for all our dreaming, end-to-end multi-AS MPLS-TE tunnels are not
>>>>    much of a thing: domains don’t like sharing information about or control of
>>>>    their network resources. Thus the “E-NNI” between slice domains may be as
>>>>    much of a service interface as the “UNI” between consumer and provider.
>>>>    2. The 5G architecture considers stitching slices from different
>>>>    technology networks to provide an end-to-end slice. From a consumer’s point
>>>>    of view, this is exactly what happens, but it is not clear to me whether
>>>>    this is really what happens in a deployment. Surely there is aggregation as
>>>>    we go down the technology layers and into the “transport” networks. That
>>>>    is, there may be very, very many micro slices in the RAN, but as this moves
>>>>    onto the IP transport, it is likely that the slicing is aggregated. That
>>>>    means that the stitching of slices actually follows a hierarchical model
>>>>    with recursion. The interface between slice domains is the “UNI”.
>>>>
>>>>
>>>>
>>>> Net-net, I like John’s original proposal. I hope we can take that as
>>>> our base point and factor in further discussions.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>> [1]
>>>> https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/
>>>>
>>>> [2] RFC 4026
>>>>
>>>> [3] draft-ietf-teas-enhanced-vpn
>>>>
>>>>
>>>>
>>>> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Young Lee
>>>> *Sent:* 24 February 2021 10:22
>>>> *To:* Luis M. Contreras <contreras.ietf@gmail.com>
>>>> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>om>;
>>>> teas@ietf.org; Eric Gray <ewgray2k@gmail.com>om>; John E Drake <
>>>> jdrake=40juniper.net@dmarc.ietf.org>gt;; Joel M. Halpern <
>>>> jmh@joelhalpern.com>gt;; mohamed.boucadair@orange.com
>>>> *Subject:* Re: [Teas] network Slice Endpoint in
>>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>>
>>>>
>>>>
>>>> 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>rg>; 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
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> Teas@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>> Spring, MD
>>>
>>> _______________________________________________
>>> Teas mailing list
>>> Teas@ietf.org
>>> https://www.ietf.org/mailman/listinfo/teas
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>