Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Shunsuke Homma <s.homma0718@gmail.com> Wed, 03 March 2021 18:06 UTC
Return-Path: <s.homma0718@gmail.com>
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 497E13A17B8 for <teas@ietfa.amsl.com>; Wed, 3 Mar 2021 10:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.847
X-Spam-Level:
X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oPtJymeNJ6kr for <teas@ietfa.amsl.com>; Wed, 3 Mar 2021 10:06:00 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CC13A17BD for <teas@ietf.org>; Wed, 3 Mar 2021 10:05:54 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id v14so11045042ilj.11 for <teas@ietf.org>; Wed, 03 Mar 2021 10:05:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oSOlDD8nAgFF3i1Tk4HZ2mkVJ0xEu6qglEX8L7Q2a/k=; b=U8AQIe9Y3QOoQCoMWDvlPvoVYS5EV4cW2899w4Tzr8xQZibdtzcnNvecG0jcilC3bY XsCtCUwGVN/XMWNVq1WRQ0rqhbdrx2Co8eYN1EZJcoKW/FJiqzCC5qZUAgilJ+1METf1 zQRQCL7433cPDwe/t3Y6tFiDzr6RZVeLqVkhXh87RtHCcBPRpAxV+xa8BBVwsTaCbI7E zruo2MUkjHaFSKwWaPpBwU1n0eRfwmoTaJSKMWsbb0pLRA8yNao6YmnKGM/A6nAjnFv4 h8s4W573vGtpKFT8hb04iVfdlId3J22Tikb95r2kPeAxERAcTGuIXuT1veMpvhAbqdFi onCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oSOlDD8nAgFF3i1Tk4HZ2mkVJ0xEu6qglEX8L7Q2a/k=; b=geoUqX0KD0oIrL4DfjwvQLH6fORhgeuHaXV16q11KkSb13m7zihKEENNGOeeWYGbwQ KUet7dvlK3gCrLyu/ODHUHY651JP8Zww/qQqRMfrek8czs0lInYlFlgpvZqN2a7872Q4 F3uHUKVfltJUYd/Vsuv2ELtaVDZ268KFQyZB0mjtxn4wnmwiQs4q4ngBYHrMoEwh1ry9 8eqlyjoHDl9M4PZTbzpwgmWpxCGwtc8cYbCIW9J7SSrv9ocXszH67OzesTWEdOjX0EcE OUnmlOaGjTKllJI0TUC9NXQRe5/3d2YhT6LHj1Fh0PCVlxcu6A4AbZiUIEMrH+rsxLFR KnUg==
X-Gm-Message-State: AOAM533WNpRIDP7zAeBxdJRppVfDAHobo+GXrxb7OYx9PbV7WFMyH8SI hL+h509b2L04fvN9UeJfBdjo7n+UFY9Dr+du4Kw=
X-Google-Smtp-Source: ABdhPJy5y65OlCK4uz+DZfcO3S16JZc8bkbO788BsoKh10EjuQzRs60Cu66BoxMEubEzUqIt0eiP5POTFufJ55KrvqI=
X-Received: by 2002:a05:6e02:1a29:: with SMTP id g9mr488469ile.54.1614794751998; Wed, 03 Mar 2021 10:05:51 -0800 (PST)
MIME-Version: 1.0
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> <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=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> <CAKr2Fb9dXMHSJ1psYGbUvm=6J3XFfAaZ9BwNe+F4Q_moR=Ro0Q@mail.gmail.com> <CABNhwV3mZVbhbNc-W_LtfUkVnT5KhqZUNFXc+we_vwBEQKj8Gw@mail.gmail.com> <CAKr2Fb81Un6YeyE=4LPFhEpLFOn9wgzVphn8DcUMZc9vDcB9Fw@mail.gmail.com> <CABNhwV24d7QHaKceLtiJi=v=7jMiO0=n5RQEc=apeVeu8=bRqg@mail.gmail.com> <CABNhwV1bV48f1=Cq4aM8pT9qFr-acxbkTPkrkXfZURx8JeO42A@mail.gmail.com> <CAKr2Fb98qvWWHEk8ibSTujKwGC1XyyK0MQ1uAS98RDnEW3zHbA@mail.gmail.com> <CABNhwV100r8qwvt6EQD72Wq2BAMBz3EWG09xSQHWMPxFeHAxyA@mail.gmail.com>
In-Reply-To: <CABNhwV100r8qwvt6EQD72Wq2BAMBz3EWG09xSQHWMPxFeHAxyA@mail.gmail.com>
From: Shunsuke Homma <s.homma0718@gmail.com>
Date: Thu, 04 Mar 2021 03:05:40 +0900
Message-ID: <CAGU6MPfC-d7skGaR7__b-X49R8Q26zceiEvj20PR7QRytM4p1A@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Luis M. Contreras" <contreras.ietf@gmail.com>, "teas@ietf.org" <teas@ietf.org>, Eric Gray <ewgray2k@gmail.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Young Lee <younglee.tx@gmail.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="00000000000093fe8805bca5b377"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eCHCOEJKk2z6gvBEP-Ke842z9GQ>
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: Wed, 03 Mar 2021 18:06:04 -0000
Hi Gyan, 2021年3月3日(水) 11:06 Gyan Mishra <hayabusagsm@gmail.com>: > > Shunsuke, > > On Mon, Mar 1, 2021 at 10:33 AM Shunsuke Homma < > shunsuke.homma.ietf@gmail.com> wrote: > >> Hi Gyan, >> >> On Sun, Feb 28, 2021 at 11:53 PM Gyan Mishra <hayabusagsm@gmail.com> >> wrote: >> >>> Hi Shunsuke >>> >>> On Sun, Feb 28, 2021 at 9:30 AM Gyan Mishra <hayabusagsm@gmail.com> >>> wrote: >>> >>>> Hi Shunsuke >>>> >>>> On Sat, Feb 27, 2021 at 11:21 PM Shunsuke Homma < >>>> shunsuke.homma.ietf@gmail.com> wrote: >>>> >>>>> Hi Gyan, >>>>> >>>>> Please see inline. >>>>> >>>>> On Sun, Feb 28, 2021 at 3:37 AM Gyan Mishra <hayabusagsm@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi Shunsuke >>>>>> >>>>>> On Sat, Feb 27, 2021 at 9:06 AM Shunsuke Homma < >>>>>> shunsuke.homma.ietf@gmail.com> wrote: >>>>>> >>>>>>> Hi Gyan, >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> On Sat, Feb 27, 2021 at 5:35 PM Gyan Mishra <hayabusagsm@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Shunsuke >>>>>>>> >>>>>>>> On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma < >>>>>>>> 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”. >>>>>>>> >>>>>>> >>>>>>> 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? > > Shunsuke> I'm still deciding which terms would be better, but I personally think that there are no problems to use PE / CE for this case. # The definition draft's authors will provide a result of analysis about endpoint soon. > >> >>> >>>>> >>>>>> >>>>>>> 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 <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> 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> 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> 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] *On Behalf Of *Adrian >>>>>>>>>>>>> Farrel >>>>>>>>>>>>> *Sent:* Thursday, February 25, 2021 6:52 PM >>>>>>>>>>>>> *To:* 'Young Lee' <younglee.tx@gmail.com>; 'Luis M. >>>>>>>>>>>>> Contreras' <contreras.ietf@gmail.com> >>>>>>>>>>>>> *Cc:* 'Joel M. Halpern' <jmh@joelhalpern.com>; teas@ietf.org; >>>>>>>>>>>>> 'Eric Gray' <ewgray2k@gmail.com>; 'John E Drake' <jdrake= >>>>>>>>>>>>> 40juniper.net@dmarc.ietf.org>; 'Rokui, Reza (Nokia - >>>>>>>>>>>>> CA/Ottawa)' <reza.rokui@nokia.com>; >>>>>>>>>>>>> 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> *On Behalf Of *Young Lee >>>>>>>>>>>>> *Sent:* 24 February 2021 10:22 >>>>>>>>>>>>> *To:* Luis M. Contreras <contreras.ietf@gmail.com> >>>>>>>>>>>>> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>; >>>>>>>>>>>>> teas@ietf.org; Eric Gray <ewgray2k@gmail.com>; John E Drake < >>>>>>>>>>>>> jdrake=40juniper.net@dmarc.ietf.org>; Joel M. Halpern < >>>>>>>>>>>>> jmh@joelhalpern.com>; 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>님이 작성: >>>>>>>>>>>>> >>>>>>>>>>>>> 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> >>>>>>>>>>>>> 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] >>>>>>>>>>>>> *Envoyé :* mardi 23 février 2021 23:46 >>>>>>>>>>>>> *À :* Eric Gray <ewgray2k@gmail.com> >>>>>>>>>>>>> *Cc :* BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>; >>>>>>>>>>>>> Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>; John >>>>>>>>>>>>> E Drake <jdrake=40juniper.net@dmarc.ietf.org>; teas@ietf.org; >>>>>>>>>>>>> Joel M. Halpern <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 >>>>>>>>>>>>> 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 >>>>>>>>>>>> Teas@ietf.org >>>>>>>>>>>> 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 > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >
- [Teas] network Slice Endpoint in draft-ietf-teas-… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel Halpern Direct
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Kiran Makhijani
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Uma Chunduri
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Uma Chunduri
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… tom petch
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Daniele Ceccarelli
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Kiran Makhijani
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Greg Mirsky
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Eric Gray
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Luis M. Contreras
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Luis M. Contreras
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Young Lee
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Young Lee
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Dongjie (Jimmy)
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Ogaki, Kenichi
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Shunsuke Homma
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Gyan Mishra
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Joel M. Halpern
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Tarek Saad
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Greg Mirsky
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Tarek Saad
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Tarek Saad
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Adrian Farrel
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Krzysztof Szarkowicz
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… John E Drake
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair
- Re: [Teas] network Slice Endpoint in draft-ietf-t… Krzysztof Szarkowicz
- Re: [Teas] network Slice Endpoint in draft-ietf-t… mohamed.boucadair