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

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 27 February 2021 05:18 UTC

Return-Path: <jmh@joelhalpern.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 E35003A0FC7 for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 21:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 xLBWQ5yDgy1e for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 21:18:42 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E443A0FC4 for <teas@ietf.org>; Fri, 26 Feb 2021 21:18:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DnZYt10z9z1nvDF; Fri, 26 Feb 2021 21:18:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1614403122; bh=4ZsH8OzthOcbJYiX4b9tZZEGy9tN1u0xFx2t+wFKk2A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dRZlF8p5BrkCcXuualvZQ5dfILkWVA0Fq7JjumAZT6mSphAh9RMQLETL+3j3nYhmw Tlp8uH8lopjvRMs4gqC+kL7ntbGwmZjP0ugofCoCPvlwLApaEeFP/4vYbGHWicRNgu 4wzu0iEyHZ7kbHxj+j23z76QnFYJGNcS/T1Xxmdo=
X-Quarantine-ID: <tqgWkVab4KMH>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DnZYs3wgzz1pBkm; Fri, 26 Feb 2021 21:18:41 -0800 (PST)
To: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Cc: "teas@ietf.org" <teas@ietf.org>
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <37cb7462-31ef-55cd-fcee-2d9a765e4558@joelhalpern.com>
Date: Sat, 27 Feb 2021 00:18:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAKr2Fb9cd6F7GGq7Pw-jPpxzwQtTE7M_DY0oQ83mmENoEHkTFw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Cv8PHIOUgq5ozyQeTKLXrkuHrkI>
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 05:18:45 -0000

The ingress classifier for SFC can clearly be a PE router.  In fact, 
that is a typical case.

I would also expect for most tunnel technologies including Geneve that 
the ingress tunnel rotuer can be a PE.

Yours,
Joel

On 2/26/2021 11:59 PM, Shunsuke Homma 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 
> <mailto: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
>     <mailto: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
>         <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
>         <mailto:younglee.tx@gmail.com>>; 'Luis M. Contreras'
>         <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com>>
>         *Cc:* 'Joel M. Halpern' <jmh@joelhalpern.com
>         <mailto:jmh@joelhalpern.com>>; teas@ietf.org
>         <mailto:teas@ietf.org>; 'Eric Gray' <ewgray2k@gmail.com
>         <mailto:ewgray2k@gmail.com>>; 'John E Drake'
>         <jdrake=40juniper.net@dmarc.ietf.org
>         <mailto:40juniper.net@dmarc.ietf.org>>; 'Rokui, Reza (Nokia -
>         CA/Ottawa)' <reza.rokui@nokia.com
>         <mailto:reza.rokui@nokia.com>>; mohamed.boucadair@orange.com
>         <mailto: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/
>         <https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/>____
> 
>         [2] RFC 4026____
> 
>         [3] draft-ietf-teas-enhanced-vpn____
> 
>         __ __
> 
>         *From:*Teas <teas-bounces@ietf.org
>         <mailto:teas-bounces@ietf.org>> *On Behalf Of *Young Lee
>         *Sent:* 24 February 2021 10:22
>         *To:* Luis M. Contreras <contreras.ietf@gmail.com
>         <mailto:contreras.ietf@gmail.com>>
>         *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
>         <mailto:reza.rokui@nokia.com>>; teas@ietf.org
>         <mailto:teas@ietf.org>; Eric Gray <ewgray2k@gmail.com
>         <mailto:ewgray2k@gmail.com>>; John E Drake
>         <jdrake=40juniper.net@dmarc.ietf.org
>         <mailto:jdrake=40juniper.net@dmarc.ietf.org>>; Joel M. Halpern
>         <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>;
>         mohamed.boucadair@orange.com <mailto: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 <mailto: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
>             <mailto: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
>                 <mailto:contreras.ietf@gmail.com>]
>                 *Envoyé :* mardi 23 février 2021 23:46
>                 *À :* Eric Gray <ewgray2k@gmail.com
>                 <mailto:ewgray2k@gmail.com>>
>                 *Cc :* BOUCADAIR Mohamed TGI/OLN
>                 <mohamed.boucadair@orange.com
>                 <mailto:mohamed.boucadair@orange.com>>; Rokui, Reza
>                 (Nokia - CA/Ottawa) <reza.rokui@nokia.com
>                 <mailto:reza.rokui@nokia.com>>; John E Drake
>                 <jdrake=40juniper.net@dmarc.ietf.org
>                 <mailto:40juniper.net@dmarc.ietf.org>>; teas@ietf.org
>                 <mailto:teas@ietf.org>; Joel M. Halpern
>                 <jmh@joelhalpern.com <mailto: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 <mailto:Teas@ietf.org>
>         https://www.ietf.org/mailman/listinfo/teas
>         <https://www.ietf.org/mailman/listinfo/teas>
> 
>     -- 
> 
>     <http://www.verizon.com/>
> 
>     *Gyan Mishra*
> 
>     /Network Solutions A//rchitect /
> 
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
> 
> 
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org <mailto:Teas@ietf.org>
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
>