Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Young Lee <younglee.tx@gmail.com> Wed, 24 February 2021 10:22 UTC
Return-Path: <younglee.tx@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 C0AC53A1353 for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 02:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6EI2n-GvSgpi for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 02:22:22 -0800 (PST)
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 011AD3A1354 for <teas@ietf.org>; Wed, 24 Feb 2021 02:22:21 -0800 (PST)
Received: by mail-oo1-xc30.google.com with SMTP id e17so387621oow.4 for <teas@ietf.org>; Wed, 24 Feb 2021 02:22:21 -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=CkGu+AAYKXpeZTNLKMn99sbow42TyBI9AwJa0Z/aU6w=; b=rv2myTd7juIChkD++WpbdziWT5lM7zbPjhrmpTumVn2vxl3IbUdoqsyuRj2TZol6lN /YkUdIOaSf6GfjRB+FSgbAyO2wUmteQlwl3yCgtlWhNymdOtgbpFTedTpHPlzRWuHfdJ bm1jO+ZaZHvDpJaJCQrkaFnXBZ+UaKVU2WbneRrmed/C3uoks2vyZsG85ps9420x7tN6 eHrLW9gH9ttE5wTvQutz3PgKanivCRV+fVIBJtnq4gyqFGx6q9JFBm27zoG21dltWaaK e+DIhnTh52v5e7jzsUYimhGjtAqgUkfHGOFdSxfZBsCxap4VJVd2Av3JcGBaV7SDFrmv ZhYw==
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=CkGu+AAYKXpeZTNLKMn99sbow42TyBI9AwJa0Z/aU6w=; b=CfjLUtnS1qfPxIKq4DAWHKT9bT6hstlfOoz9EKIRNIktSRAf1e1xPDg5xawqJJ9BGu bPNlOVwBhFdye4CR+WcTu7mOFtKy8nuoT0XQqcrMcXvzAP+XOAtBu7inhsUVrLm40NIj rFSqJPiCQ3c6sDhYwBp9kVYL1aXyjMm6exF0Rf3XTPNPR4HpfWUClRlzoNP3DiqIJ4hA TR6o1rplPNHrPzNUIJ/1yLkPvd8o79HYpQIyBBZZdBqlsBk6FgZWrHQTHtzhgKvCJ/Y+ f68wCIQEXK6pAGXmlM3T/YmiHMfqwtIoFxR2W1Hh0Jq6ySixCYNwe/2JnsRNgyUuC/pj 5m5Q==
X-Gm-Message-State: AOAM531T/wGhwsg3i2cHxiPHSECTzt7C7l8paUPACGvipyMry7WZ+jDy 6N8ZzK/Fqw/dFbQbES3IIYjZDQw5mZtINAyurC8=
X-Google-Smtp-Source: ABdhPJwCXp4K9oXZmDfZXAZ8LafrvP8kPcYNz03Zmc3Gv1E1zaeDSRREKDU1PsZ+BxSAGUfEGf19vxgOnoZHvS65H5w=
X-Received: by 2002:a4a:2a0a:: with SMTP id k10mr3083170oof.88.1614162141014; Wed, 24 Feb 2021 02:22:21 -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> <22018_1614147403_6035EF4B_22018_270_1_787AE7BB302AE849A7480A190F8B9330315D8A0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com>
In-Reply-To: <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com>
From: Young Lee <younglee.tx@gmail.com>
Date: Wed, 24 Feb 2021 19:22:07 +0900
Message-ID: <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com>
To: "Luis M. Contreras" <contreras.ietf@gmail.com>
Cc: mohamed.boucadair@orange.com, Eric Gray <ewgray2k@gmail.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="00000000000006712005bc126901"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/mbeOxt_GzHNBFwOSmDD-BaG5bvo>
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, 24 Feb 2021 10:22:27 -0000
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 >> >> >> >> >> >> El mar, 23 feb 2021 a las 20:20, Eric Gray (<ewgray2k@gmail.com>) >> escribió: >> >> Reza, >> >> >> >> Please see *in-line responses* below… >> >> >> >> Note: I am trying not to repeat responses already made. If I respond to >> ay point with a similar response to ay already given, I apologize in >> advance... >> >> >> >> — >> >> Eric >> >> >> >> — [SNIP] --- >> >> >> >> *De :* Teas [mailto:teas-bounces@ietf.org <teas-bounces@ietf.org>] *De >> la part de* Rokui, Reza (Nokia - CA/Ottawa) >> *Envoyé :* mardi 23 février 2021 17:53 >> *À :* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>; BOUCADAIR >> Mohamed TGI/OLN <mohamed.boucadair@orange.com>; Joel M. Halpern < >> jmh@joelhalpern.com>; teas@ietf.org >> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> >> *Objet :* Re: [Teas] network Slice Endpoint in >> draft-ietf-teas-ietf-network-slice-definition-00 >> >> >> >> All, >> >> >> >> In summary I am in agreement for some parts. >> >> Please see a few comments inline. >> >> >> >> Reza >> >> >> >> >> >> >> >> >> >> On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <teas-bounces@ietf.org >> on behalf of jdrake=40juniper.net@dmarc.ietf.org >> <teas-bounces@ietf.org%20on%20behalf%20of%20jdrake=40juniper.net@dmarc.ietf.org>> >> wrote: >> >> >> >> Hi, >> >> >> >> Eric and I have reviewed the Definitions draft, the email thread with >> the subject line: Network Slice Endpoint in >> draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced >> in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would >> like to propose that in the Definitions draft we replace 'network slice >> endpoint' with 'CE' and 'network slice realization endpoint' with 'PE', >> that we reference RFCs 3985, 4110, 4026, 4664, and 8309, >> >> >> >> [Reza] The IETF network slice endpoints (NSE) can be mapped to some >> virtual or physical interfaces on CE or PE depends on the use-case. But the >> “IETF network slice endpoints” are not CE or PE nodes themselves. >> >> >> >> *CE and PE components are as capable of being virtual as any component >> currently included in the draft - hence it might be a littler bit >> disingenuous to assume that the end points described in the draft cannot be >> part of a CER or PE, because these are “nodes” (implying physical devices).* >> >> >> >> *If we are defining ed points specifically >> to justify using new terminology, perhaps we could stop doing that? * >> >> >> >> We have added more explanation to >> *draft-wd-teas-ietf-network-slice-nbi-yang-02* figure 4 and 5. This is >> the summary. >> >> >> >> *It is awkward to have a terminology section, or a definition draft, that >> refers to a modeling draft for explanation of the terms being defined.* >> >> >> >> >> >> “IETF network slice endpoints (NSE)” are logical entities which can be >> mapped to interfaces on CE or PE nodes depends on use-case. The following >> pictures show two use-cases where in one NSE are mapped to interface on PE >> nodes and in other one NSE are mapped to interface on CE nodes. >> >> >> >> NSE1 NSE2 >> >> (With PE1 parameters) (with PE2 parameters) >> >> o<--------- IETF Network Slice 1 ------->o >> >> + | | + >> >> + |<----------- S1 ----------->| + >> >> + | | + >> >> + | |<------ T1 ------>| | + >> >> + v v v v + >> >> + +----+ +----+ + >> >> +-----+ | | PE1|==================| PE2| +-----+ >> >> | |----------X | | | | | | >> >> | | | | | | X----------| | >> >> | |----------X | | | | | | >> >> +-----+ | | |==================| | | +-----+ >> >> AC +----+ +----+ AC >> >> Customer Provider Provider Customer >> >> Edge 1 Edge 1 Edge 2 Edge 2 >> >> >> >> >> >> >> >> NSE3 NSE4 >> >> (With CE1 parameters) (with CE2 parameters) >> >> o<--------- IETF Network Slice 2 ------->o >> >> + | | + >> >> + |<----------- S2 ----------->| + >> >> + | | + >> >> + | |<------ T2 ------>| | + >> >> + v v v v + >> >> + AC +----+ +----+ + >> >> +-----+ | | PE1|==================| PE2| +-----+ >> >> | |----------X | | | | | | >> >> | | | | | | X----------| | >> >> | |----------X | | | | | | >> >> +-----+ | | |==================| | | +-----+ >> >> AC +----+ +----+ AC >> >> Customer Provider Provider Customer >> >> Edge 1 Edge 1 Edge 2 Edge 2 >> >> >> >> >> >> Legend: >> >> O: Representation of the IETF network slice endpoints (NSE) >> >> +: Mapping of NES to PE or CE nodes on IETF network >> >> X: Physical interfaces used for realization of IETF network slice >> >> S1: L0/L1/L2/L3 services used for realization of IETF network slice >> >> T1: Tunnels used for realization of IETF network slice >> >> >> >> >> >> and that we replace the current figure in Endpoint section with several >> figures, which show connectivity constructs and which are consistent with >> these RFCs. >> >> [Reza] It is fine. Please suggest a figure and it can be included in draft >> >> >> >> We would also like to replace 'consumer' with 'customer', >> >> [Reza] Fine >> >> >> >> add 'attachment circuit', and add a new term, viz, 'IETF Network Slice >> Service', >> >> [Reza] Why new term? This is what it is called “IETF Network Slice”. >> >> >> >> *This is not so much a new term as a clarification for the phrase “IETF >> Network Slice” when applied to a “service interface.”* >> >> >> >> *In order to describe a interface generic enough to be applied in any >> technology agnostic fashion, we should be defining a “service” interface >> (as is obvious from the choice to describe this in “service” terms - i.e. >> - “service level objectives”).* >> >> >> >> *If we use the phrase “IETF Network Slice Service,” it is clearer that we >> are referring to a “service-based” abstraction of any underlying “IETF >> Network Slice."* >> >> >> >> >> >> whose definition is a set of CEs, a set of connectivity constructs >> (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for each >> CE sending to each connectivity construct. >> >> >> >> As an aside, the Endpoint section of the Definitions draft uses the >> bulk of its prose enumerating what its endpoints are not. Per Yakov, since >> there are a potentially infinite number of things which its endpoints are >> not, this is futile and we would like to remove that prose. >> >> [Reza] which part of draft are you referring? >> >> >> >> *I had not thought this to be too subtle to be grasped by any observer >> that has been following the discussion on end point definitions.* >> >> >> >> *The primary discussion in the draft is in section 4.2 (IETF Network >> Slice Endpoints). * >> >> >> >> *However, the term “endpoint” appears quite often and is entirely unclear >> that there is more than one type of endpoint in almost all cases. Hence, >> because we have defined these in a new way, it is as if we need to refer >> (at least) to section 4.2 each and every time we use the term - and clarify >> which type of endpoint we are actually using in each case.* >> >> >> >> *If we were clear that we are referring to “IETF Network Slice >> Service” endpoints, there is a more common term we could use to describe >> the relationship between the endpoints and the network components where >> they may occur. A set of terms that are not only commonly used, but well >> understood in the industry.* >> >> >> >> >> >> Yours Irrespectively, >> >> >> >> Eric and John >> >> >> >> — [SNIP] --- >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> >> >> >> -- >> >> ___________________________________________ >> >> Luis M. Contreras >> >> contreras.ietf@gmail.com >> >> luismiguel.contrerasmurillo@telefonica.com >> >> Global CTIO unit / Telefonica >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> > > -- > ___________________________________________ > Luis M. Contreras > contreras.ietf@gmail.com > luismiguel.contrerasmurillo@telefonica.com > Global CTIO unit / Telefonica > _______________________________________________ > 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