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

[Gyan Mishra <[e-mail]>]

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 <
[e-mail]> 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]> 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]>
>> 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
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>
>> _______________________________________________
>> 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