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

[Gyan Mishra <[e-mail]>]

Hi Shunsuke

On Sun, Feb 28, 2021 at 9:30 AM Gyan Mishra <[e-mail]> wrote:

> Hi Shunsuke
>
> On Sat, Feb 27, 2021 at 11:21 PM Shunsuke Homma <
> [e-mail]> wrote:
>
>> Hi Gyan,
>>
>> Please see inline.
>>
>> On Sun, Feb 28, 2021 at 3:37 AM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>>
>>> Hi Shunsuke
>>>
>>> On Sat, Feb 27, 2021 at 9:06 AM Shunsuke Homma <
>>> [e-mail]> wrote:
>>>
>>>> Hi Gyan,
>>>>
>>>> Please see inline.
>>>>
>>>> On Sat, Feb 27, 2021 at 5:35 PM Gyan Mishra <[e-mail]>
>>>> wrote:
>>>>
>>>>> Shunsuke
>>>>>
>>>>> On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> 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...)
>>>>>>
>>>>>
>>>>>    Gyan> Agreed no PE/CE handoff.  For any of the NOV3 overlay
>>>>> encapsulations  types the decapsulation happens on the leaf before packet
>>>>> is handed off to host endpoint.  Because it’s a host endpoint which would
>>>>>  be a server and not a customers  “CPE” gear CE switch or router as in the
>>>>> MPLS world or even with broadband BNG subscribers.  So that’s the big
>>>>> difference in the Data Center framework from an operators perspective that
>>>>> is all the operators domain.  You can think of if from a cloud perspective
>>>>> the network infrastructure is IAAS “infrastructure as a service” and server
>>>>> infrastructure is PAAS “platform as a service”.
>>>>>
>>>>
>>>> Shunsuke > Thank you for your elaboration. As you pointed out,
>>>> frameworks of NSP network and Data Center are different, and it may be
>>>> difficult to  manage with the same model. Meanwhile, in network slicing, it
>>>> is needed to  provide "E2E" connectivity guaranteed specific SLA/SLO, and
>>>> network slice will be sometimes deployed across both NSP network and Data
>>>> Center. For example, in a smart factory scenario, robots may be connected
>>>> to their operating server on NSP's cloud with Geneve-based network slice.
>>>> Then, a slice endpoint will be Geneve tunnel endpoint, neither CE nor PE.
>>>>
>>>
>>>     Gyan> In a DC NVO3 overlay / underlay model typical leaf/spine CLOS
>>> folded spine architecture, the  demarcation is clearly defined if you apply
>>> the MPLS parity to DC NVO3 directly.   In that framework the spine nodes
>>> are like the P routers performing in line data plane forwarding similar to
>>> P label switching leaf to leaf over the folded spine as well as termination
>>> of control plane and the leafs terminating NVO3 tunnel endpoint vtep for
>>> vxlan for example perform the encapsulation / decapsulation similar to PE
>>> label imposition and disposition.  So applying the same MPLS parity to NVO3
>>> the leaf would be the PE and the TOR connected switch would then be the
>>> CE.  So the same PE/CE nomenclature can still apply.
>>>
>>> For non NVO3 BGP only DC CLOS folded spine architecture we still have
>>> the leaf and spine nodes  and here also the leaf would be the PE and TOR
>>> hanging off the leaf would be the CE.
>>>
>>> I think in any model even in GMPLS mode for example where you have an
>>> peering adjacency such as inter-as tie that would be your NNI PE-PE
>>> relationship.
>>>
>>> As far as SFC classifier that would be on the leaf switch acting as the
>>> PE demarcation to the CE TOR switch.
>>>
>>> So you can really apply the PE/CE nomenclature ubiquitously to any
>>> scenario.
>>>
>>
>> Shunsuke > Thank you very much. I understood that PE/CE model can be
>> applied in every network slice scenario from the aspect of traffic
>> handoffs. I agree with that, and it seems reasonable.
>>
>
>     Gyan> Great.  I think we are making progress.😀
>
>>
>> Then, my next concern is whether we should bring terms of MPLS world to
>> overlay world. (It depends on the realization, but I assume network slices
>> will be realized with overlay technologies in many cases.) NVO3 and other
>>  overlay technologies use "endpoint", and I feel it is more compatible to
>> network slice scenarios. NSE can be also applied to every network slice
>> scenario. As Reza mentioned, NSE is a logical entity of network slice layer
>> and will be mapped to (virtual/physical) node in technology layer such as
>> CE//PE for MPLS, VNE, VTEP, etc.
>>
>
>     Gyan> The concept of underlay/overlay actually historically started
> with any framework where you have a concept of multi tenancy or multiple
> customer framework that broadened the single tenant IP based framework to a
> logical construct by creating a “hypervisor like” overlay/underlay model
> now called “MPLS”.  MPLS can be utilized as a single tenant model similar
> to IP based model in an enterprise MPLS framework where the PE-CE edge is
> native IP “no VRF” or virtualization of the edge layer using “global table”
> single layer no overlay routing PE-RR SAFI 1 for IPv4 and SAFI 4 for IPv6
> BGP LU (6PE) to connect IPv6 islands over an MPLS core. “MPLS” can also be
> user in a Service Provider mode of “multi tenancy” multi customer model
> identical to NVO3 with a virtualization “hypervisor like” layer added with
> now populating the label stack two layers deep with now a virtualization of
> the PE-CE edge layer with VRF concept similar to a VM VNF on a NFV
> framework, so now the topmost transport label is the  underlay global table
> routing and your bottom of stack a label BOS bit set is your virtualization
> layer VPN “overlay” layer identical to NVO3 “overlay/underlay” concept.  So
> the idea of tunneling is tunnel endpoint and tunnel termination point is
> not new and applies to any framework where you have encapsulation and
> decapsualation occurring in MPLS it’s imposition and disposition of the
> Label stack to forward native IP to the CE edge end in NVO3 it’s the same
> removal of the outer envelope to forward native IP to the edge.  The
> virtualization layer in both cases stops at the PE edge when the handoff
> occurs from PE to CE as now the CE edge sits in the global table routing.
> This is true any overlay/underlay architecture with MPLS and NVO3 as direct
> parity examples.  We can actually think of the concept of network slice
> framework as a pre existing condition of any overlay / underlay model as
> logically the overlay “VPN overlay” or “NVO3 overlay”  is a slice of the
> physical with the virtualization layer terminating on what we call today a
> “PE” and tomorrow with network slice paradigm shift with my parity added in
> the paradigm shift we end up still calling it a “PE”.
>
>>

>>
>> Also, I think some modification or extension of definitions of CE/PE for
>> these usage if we use CE/PE terms instead of NSE. As Kenichi pointed,
>> "customer" of CE actually means "consumer". PE may mean edge of IETF
>> technology-enabled domain, not provider network, in such usage.
>>
>
>     Gyan> Agreed.
>
>>
>>
>> Anyway, I don't see any serious problems whichever is chosen, and think
>> this is a matter of taste finally. Or we need more consideration from
>> different aspects.
>>
>
>     Gyan> The major take away here is in my mind is added industry
> confusion or layer of abstraction as it may be with new nomenclature where
> we are really still talking about the same endpoint type.  Nothing has
> really changed, but it’s just wrapping our heads around the network slice
> concept where in reality it has existed for decades.
>

    Gyan> So the concept of “network slice” is half way there with the
slide concept being a pre existing condition with the overlay VPN or NVO3
overlay concept.  The second half of the slicing that was missing that is
now being added is the underpinnings of VPN overlay which is already sliced
to the underlay now extending the overlay slicing to the underlay slice of
resources.  From a cross sectional standpoint if you think of a pie the
knife went half way through the slice but landed in the middle bottom half
being the underlay but now when the knife goes all the way through the
cross section now you have slice of pie which is the “network slice”.

>
>>
>>
>>>
>>>> For customers, it would be better that they can always request a slice
>>>> with the same information/data model whatever their target is. If there are
>>>> cases where CE/PE can't be fit, I think we should avoid using them as a
>>>> slice endpoint.
>>>> # If we focus on only transport (i.e., IP/MPLS based network) and never
>>>> extend the scope to other fields, it's ok to use CE/PE.
>>>>
>>>>
>>>>
>>>>>>
>>>>>> 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 <[e-mail]>
>>>>>> 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 <
>>>>>>> [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
>>>>>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>>>>>> Spring, MD
>>>>>>>
>>>>>>> --
>>>>>
>>>>> <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
>>>>>
>>>>> --
>>>
>>> <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
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD