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

[Gyan Mishra <[e-mail]>]

Shunsuke,

On Mon, Mar 1, 2021 at 10:33 AM Shunsuke Homma <
[e-mail]> wrote:

> Hi Gyan,
>
> On Sun, Feb 28, 2021 at 11:53 PM Gyan Mishra <[e-mail]>
> wrote:
>
>> 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.
>>>
>>
>> Shunsuke > In the recent network slicing concept, I think that two
> factors are added to the existing traditional network model: E2E coverage
> and on-demand provisioning by automation. In many cases, IETF network is a
> part of the entire network connecting end hosts, and an E2E network slice
> would be realized with combining network slices deployed over different
> type of networks. Also, in the future, deployment of each network slice and
> combining them will be fully automated with orchestrators (for E2E and each
> domain). Then, what should be prior in IETF Network Slice NBI may not be
> providers' aspect but one consumer, including customers and orchestrators.
> In short, terms which are general and unified independently of underlay
> types may be needed.
> # This is just one option, and I don't say that the PE-CE model is
> inappropriate from such a perspective.
>
>
>>     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”.
>>
>>>
>>>> Shunsuke > That's a very important point. What we need is a framework
> for linking overlay and underlay resources.
>

    Gyan> Understood.  We have the framework draft.

https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-07

Are you good then with using the historical PE / CE nomenclature?


>
>>
>>>>
>>>>>
>>>>>> 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
>>> <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