Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Shunsuke Homma <shunsuke.homma.ietf@gmail.com> Sat, 27 February 2021 04:59 UTC
Return-Path: <shunsuke.homma.ietf@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 4BB0F3A0E82 for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 20:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.087 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_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 Uo3SR0w3J2IR for <teas@ietfa.amsl.com>; Fri, 26 Feb 2021 20:59:23 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 C00583A0EC0 for <teas@ietf.org>; Fri, 26 Feb 2021 20:59:22 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id f1so17042188lfu.3 for <teas@ietf.org>; Fri, 26 Feb 2021 20:59:22 -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=BFzWYEwS+9tyJPn3RiTLjnVCKFMKjOk5deKTMVNpUcU=; b=E7iUdqnQN7QGZJdD6S6ad/I2kPMUpBE1pCABIhMRP/C2VzgPuwfTqkkms7P8mPQjmr h7CMy4h2FlLkGpUDAzLYTtDk4q5Ffe6YLXKFZmzN0CSFUA9tfo9NfXoZrYhf03ZkclcW z5qsWfK+lP5GGyUMhwQBRbpcgrkYtY6tl4HRuORs0yR/kT0wWCjhpdKNgKDI4rx6HSsj 9Me9TkrRUa4mXLk7e5pNdzX0UhYE8JcjpoWX85O/7CHAZDoASrKQspf3MXKUBOGWqDg1 Um1KVDXEeqoEtLvRGm5tJeXJGAm0dH0zhVCDOEhPDgmEKX2mJh5f/ogxYbJjFv2qDwO6 9sJg==
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=BFzWYEwS+9tyJPn3RiTLjnVCKFMKjOk5deKTMVNpUcU=; b=EWPrurE8742VcDwwvaM9R8QXvEo7DDs67AJe0wl/bsr2ZJ4YVgYuQz5Bb5jGGYWxGe o7NZTt8Zu8/BfanKz+trK9MeUBoqgOBhFnsbkcHkhXGjntlXnB7ABHoWcCFdrsTPtVAW OuoA7wcHb8cvuGvxM5LYLW4yXzxosUtHrA8LVzQ9mE08qCOidcgXsudjLBfVp5zjMqor q1fyXhNsc1LzE1VIdYjRVdd+bomKdXSoyP3FqHg2TIPA/c8fFxJumGECOqTlhTwtWCC/ NXP/jyna42nxft8PyjbiDXUEJBQOyCkgSRv11oV1ECR9HgQanZVwWz9HWh39H6lMgkek eZdw==
X-Gm-Message-State: AOAM530XoCXMvY7OLwRPfTg4ajVIUdngB7k8Xzchh27unsplfF5dVvSI m2bvl4ebve0MPm1JYSIcOKOaYfk1TD2/SalkHfFq47dDY/w=
X-Google-Smtp-Source: ABdhPJz0hgQvAd58LCyPJh9mZocX8EtlcusXiTJQB9GPcBrTBES0lQwngO+NQ6v4i0fszaGhrnCBHJkA9Yxcsyj0Oco=
X-Received: by 2002:ac2:53a1:: with SMTP id j1mr3644610lfh.298.1614401960786; Fri, 26 Feb 2021 20:59:20 -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>
In-Reply-To: <CABNhwV2ZVT47m17KARJDjXzr232bs5srp2KdD7njmgTPw0=8BQ@mail.gmail.com>
From: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Date: Sat, 27 Feb 2021 13:59:09 +0900
Message-ID: <CAKr2Fb9cd6F7GGq7Pw-jPpxzwQtTE7M_DY0oQ83mmENoEHkTFw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@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" <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="00000000000065bd3505bc4a3f12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/tV1bWrOCCGhxMP84wgnTL79o_zU>
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 04:59:26 -0000
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 *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