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

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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) <[e-mail]
>     <mailto:[e-mail]>> 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:[e-mail]
>         <mailto:[e-mail]>] *On Behalf Of *Adrian Farrel
>         *Sent:* Thursday, February 25, 2021 6:52 PM
>         *To:* 'Young Lee' <[e-mail]
>         <mailto:[e-mail]>>; 'Luis M. Contreras'
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc:* 'Joel M. Halpern' <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; 'Eric Gray' <[e-mail]
>         <mailto:[e-mail]>>; 'John E Drake'
>         <jdrake=[e-mail]
>         <mailto:[e-mail]>>; 'Rokui, Reza (Nokia -
>         CA/Ottawa)' <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>
>         *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 <[e-mail]
>         <mailto:[e-mail]>> *On Behalf Of *Young Lee
>         *Sent:* 24 February 2021 10:22
>         *To:* Luis M. Contreras <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; Eric Gray <[e-mail]
>         <mailto:[e-mail]>>; John E Drake
>         <jdrake=[e-mail]
>         <mailto:jdrake=[e-mail]>>; Joel M. Halpern
>         <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[e-mail]>
>         *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
>         <[e-mail] <mailto:[e-mail]>>님이
>         작성:____
> 
>             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,
>             <[e-mail]
>             <mailto:[e-mail]>> 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:[e-mail]
>                 <mailto:[e-mail]>]
>                 *Envoyé :* mardi 23 février 2021 23:46
>                 *À :* Eric Gray <[e-mail]
>                 <mailto:[e-mail]>>
>                 *Cc :* BOUCADAIR Mohamed TGI/OLN
>                 <[e-mail]
>                 <mailto:[e-mail]>>; Rokui, Reza
>                 (Nokia - CA/Ottawa) <[e-mail]
>                 <mailto:[e-mail]>>; John E Drake
>                 <jdrake=[e-mail]
>                 <mailto:[e-mail]>>; [e-mail]
>                 <mailto:[e-mail]>; Joel M. Halpern
>                 <[e-mail] <mailto:[e-mail]>>
>                 *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
>         [e-mail] <mailto:[e-mail]>
>         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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
>