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

[Gyan Mishra <[e-mail]>]

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