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

Adrian Farrel <adrian@olddog.co.uk> Sat, 27 February 2021 18:24 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C377F3A0E66 for <teas@ietfa.amsl.com>; Sat, 27 Feb 2021 10:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.893
X-Spam-Level:
X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIss1qtiqiFJ for <teas@ietfa.amsl.com>; Sat, 27 Feb 2021 10:24:48 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705693A0E53 for <teas@ietf.org>; Sat, 27 Feb 2021 10:24:46 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11RIOV8c027554; Sat, 27 Feb 2021 18:24:31 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 27D342203B; Sat, 27 Feb 2021 18:24:31 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1A39A2203A; Sat, 27 Feb 2021 18:24:31 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.2.163]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11RIOTDT013449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Feb 2021 18:24:29 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Ogaki, Kenichi'" <ke-oogaki@kddi.com>, "'Gyan Mishra'" <hayabusagsm@gmail.com>, "'Shunsuke Homma'" <shunsuke.homma.ietf@gmail.com>
Cc: "'Dongjie \(Jimmy\)'" <jie.dong@huawei.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, "'Luis M. Contreras'" <contreras.ietf@gmail.com>, <teas@ietf.org>, "'Eric Gray'" <ewgray2k@gmail.com>, "'John E Drake'" <jdrake=40juniper.net@dmarc.ietf.org>, "'Young Lee'" <younglee.tx@gmail.com>, "'Rokui, Reza \(Nokia - CA/Ottawa\)'" <reza.rokui@nokia.com>, <mohamed.boucadair@orange.com>
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com> <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <cde51de3-4533-9acd-a654-59a1dc9f195b@joelhalpern.com> <11878_1613494720_602BF9C0_11878_194_1_787AE7BB302AE849A7480A190F8B9330315CF9FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <71F75531-DE7E-419E-890D-A5AB6D5F4D8F@nokia.com> <27179_1614103167_6035427F_27179_485_2_787AE7BB302AE849A7480A190F8B9330315D83ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <54DAE6D4-7435-4E1A-9538-51F2ED35B132@gmail.com> <CAE4dcxnhjszy7OMD-JusSnDBg2oR7Buo4XKO6gXk1-DrQc2FsA@mail.gmail.com> <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com> <! CAGHSPWNmr3RQrSGsbsEvyG oLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com> <069101d70b64$3d32bf10$b7983d30$@olddog.co.uk> <81cdb36e29e64fd79bafeb578926e6a8@huawei.com> <CABNhwV2ZVT47m17KARJDjXzr232bs5srp2KdD7njmgTPw0=8BQ@mail.gmail.com> <CAKr2Fb9cd6F7GGq7Pw-jPpxzwQtTE7M_DY0oQ83mmENoEHkTFw@mail.gmail.com> <CABNhwV3Dz86VkePniMGmF6vOvu63VEN9J-izHZ__=qn97cqzdg@mail.gmail.com> <CAKr2Fb9f9B-BUobJGV2X90tCUdAtHzoZHWth4nbqKG9cN3r1Gg@mail.gmail.com>, <CABNhwV0q82AobMnSBYfSaCRUNKe9=yb=ZrTFaS1YGF-UOFBeWQ@mail.gmail.com> <TY2PR01MB3562576B3D3671DD743BE1B9909C9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB3562576B3D3671DD743BE1B9909C9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
Date: Sat, 27 Feb 2021 18:24:28 -0000
Organization: Old Dog Consulting
Message-ID: <03ac01d70d35$c9e69a80$5db3cf80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_03AD_01D70D35.C9EA1CF0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKkHwJGzCaQ8Mp5a65/8LWCXraT6QKYoIm5AZRKeBQCNZIg8QHABUFOATfBGTcBuyoGHgG6ih2LAmHrtcEBvFllmQCoCD/GAlG4NkAC4AgCBgIQP8i1AXVHTTABWEATyAJTvwOoAd9lggQCLUQ+BgFWbFEmAbrOd4mnqXECUA==
Content-Language: en-gb
X-Originating-IP: 84.93.2.163
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003
X-TM-AS-Result: No--24.447-10.0-31-10
X-imss-scan-details: No--24.447-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--24.446800-10.000000
X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgyjbUGrNyTh5osrmVXtiCtfQS1q41cbv5ZejF WkoAvZU31ghFeVHEJqd7n2QtD8/lpMmR5yDJkPg4K1zvw58Eecu7tUn/eK6OKdhA5t9XVkHvGUj vPyaNTvnwZBITD8PAy43YIvqT9T7DJP29N7gUd1DThmt8qRASYGfTKTAQ/SGbL3cbWSYN50y1h3 Ci3ttLralJxyhSjL7kJ7g2As83vh5uaOJ0WBxs0qccEhvIyMIUY9tXPGh/u0MjqjdFusfoJMX6l qk4FA2mrLgyFt75rKIZ1VI1DVL4ZcGNvKPnBgOa5RMDFPANjSjC5sPdIVtbO3/kmGO77dgJen1x 55VBWeGQZ7O3Mq+OQYVVY0f2VRT1iUtr3mVsQJh4ssIDQ8PtqH8ozV5Wwb50dGaJMmPvEyzFa6Q LFsLubIN86bMbdBNQRRQhvLCBVE/2b09s2KGDsHl2c9WreWzsPeOHPOUGOYgYqGRoBQ3fc02K0K a7xQ6igwK5LlY9YNVxayFiZmkPbwCNFKULxGCZ5O1s01MUhB3fUZT83lbkEH8959tRYfUfggBMy tb7vb35QZGJaQ6z3aVt9Sdtb44dXmFVlObh0Pz8UhyKVtzg32/9bh5q9RJqzodOm+zp8KktIlsE JXCeuOXS9YOe46umS6V4rYy9FgOJkf5qQgIh3Vx3Y/7RAcpGyUwbLBuaxfeVjF4ez76JI+xeDkf BdCrgtFuzUzWUl06X/wbQIOKBulHmrymVJ0uQ0xb25/X+gto26LA298cW3FpwgWwusAwSRE66n5 jBgkFDtd6Fiyv5U6YeOiYJ7x75U+OjsPhIWDjG0EHapv1eJ2RinB1Mnjd9lR1cT9YafQVWhNrmU WSdQTdMIbYnAMVFlxG9E4+R9XWw7M6dyuYKg4VH0dq7wY7uzQiwuqJox4Qgh59TdhIFyB6AEaoO o6PNcVAgp09W/Utd1kOkQGFHwg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/V8ow_uptUZXHemdvHXggd7mqxU4>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Feb 2021 18:24:52 -0000

As always, Kenichi makes some good points.

 

The term “customer” is also open to debate. For some people it means a person who pays for a service, but others just see it as the person or organisation that makes use of a service. I think this is why we started to use “consumer” in the context of network slicing. Hopefully we are all agreed that the IETF network slice is a recursive concept and the consumer of a slice could be:

*	A paying customer (probably organisational)
*	Another division of the service provider (thinking of mobile and transport divisions)
*	A structural optimisation of service provision (e.g., aggregation)

 

Best,

Adrian

 

From: Ogaki, Kenichi <ke-oogaki@kddi.com> 
Sent: 27 February 2021 11:08
To: Gyan Mishra <hayabusagsm@gmail.com>om>; Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Joel M. Halpern <jmh@joelhalpern.com>om>; Luis M. Contreras <contreras.ietf@gmail.com>om>; teas@ietf.org; Eric Gray <ewgray2k@gmail.com>om>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; adrian@olddog.co.uk; Young Lee <younglee.tx@gmail.com>om>; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>om>; mohamed.boucadair@orange.com
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

 

Hi All,

This is interesting discussion.

Each party can find any number of counterevidences against the opposite party even from existing RFCs since there might have been no discussion like this or there are different solutions for different usecases.

Anyway, I prefer PE/CE even as one of mobile operators.
IMHO, PE/CE concept has already gone beyond customer handoff/demarcation point. Although Adrian indicated PWE3 diagram, I usually see that CE-PE boundary inside our own (operator's internal) network rather than a customer handoff point. Even in our DC, our IP network division provides any connectivity service inside/outside DC to the other division as well as our real customers, as a CE-PE model.
In other words, C in CE actually means not real customer but whoever consumer of a connectivity service.

Thanks,
Kenichi

  _____  

From: Teas <teas-bounces@ietf.org> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
Sent: Saturday, February 27, 2021 5:35 PM
To: Shunsuke Homma
Cc: Dongjie (Jimmy); Joel M. Halpern; Luis M. Contreras; teas@ietf.org; Eric Gray; John E Drake; adrian@olddog.co.uk; Young Lee; Rokui, Reza (Nokia - CA/Ottawa); mohamed.boucadair@orange.com
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00 

 

Shunsuke

 

On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <shunsuke.homma.ietf@gmail.com <mailto:shunsuke.homma.ietf@gmail.com> > 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”.



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 <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> > 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 <shunsuke.homma.ietf@gmail.com <mailto:shunsuke.homma.ietf@gmail.com> > 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 <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> > 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) <jie.dong@huawei.com <mailto:jie.dong@huawei.com> > 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:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> ] On Behalf Of Adrian Farrel
Sent: Thursday, February 25, 2021 6:52 PM
To: 'Young Lee' <younglee.tx@gmail.com <mailto:younglee.tx@gmail.com> >; 'Luis M. Contreras' <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com> >
Cc: 'Joel M. Halpern' <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >; teas@ietf.org <mailto:teas@ietf.org> ; 'Eric Gray' <ewgray2k@gmail.com <mailto:ewgray2k@gmail.com> >; 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org <mailto:40juniper.net@dmarc.ietf.org> >; 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >; mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> 
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 <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > On Behalf Of Young Lee
Sent: 24 February 2021 10:22
To: Luis M. Contreras <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com> >
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >; teas@ietf.org <mailto:teas@ietf.org> ; Eric Gray <ewgray2k@gmail.com <mailto:ewgray2k@gmail.com> >; John E Drake <jdrake=40juniper.net@dmarc.ietf.org <mailto:jdrake=40juniper.net@dmarc.ietf.org> >; Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >; mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> 
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 <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com> >님이 작성:

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, <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> > 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:contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com> ] 
Envoyé : mardi 23 février 2021 23:46
À : Eric Gray <ewgray2k@gmail.com <mailto:ewgray2k@gmail.com> >
Cc : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> >; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >; John E Drake <jdrake=40juniper.net@dmarc.ietf.org <mailto:40juniper.net@dmarc.ietf.org> >; teas@ietf.org <mailto:teas@ietf.org> ; Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >
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
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas

-- 

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

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>  
Silver Spring, MD

 

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas

-- 

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

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 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 Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD