Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
Gyan Mishra <hayabusagsm@gmail.com> Sat, 29 August 2020 20:28 UTC
Return-Path: <hayabusagsm@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 9C0493A0FDD for <teas@ietfa.amsl.com>; Sat, 29 Aug 2020 13:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 nFKMNsVu2iCw for <teas@ietfa.amsl.com>; Sat, 29 Aug 2020 13:28:48 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 38BED3A0FDB for <teas@ietf.org>; Sat, 29 Aug 2020 13:28:48 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id x17so839204uao.5 for <teas@ietf.org>; Sat, 29 Aug 2020 13:28:48 -0700 (PDT)
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=zdXCgQ5o+AHy0/H80fdWBuqFYjWZbcJsC+N8HilAiRk=; b=B+szVF+vputR75aByk5/QKjict3yAYJNrrrjoOUF1SlpKu9oU3VZUaCyNL0HAiB9Cv TE0Z6sMN75plhDf371RdwaAs9NuCw/6WKXfCWCsCgeZeY49wMGLOO5/o150yiJjl5oWD riY21orx8GviDkez0Go9oONX5go2K6noVx90eCUQmB8C7L2NQZVR0Z+LHmeH8yXPaYhc m8jd6saiasx5AgsJm/vhlsjDNuSEtDdrPxfCE074wOCQWhkD6F3edoz2SIkTqjh3/ZP+ a/7lDrv6a7xzbe7rFjvsIO+P0gdAswTaSybS471iULhwE91hGVkvqxYcLNPgwyMgToPg KcNA==
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=zdXCgQ5o+AHy0/H80fdWBuqFYjWZbcJsC+N8HilAiRk=; b=d/0inCM2rvIvh46EBCWraOC4mKFkPCtFR0eT+3foHabrg8vX5mn3LNFnZpftEjkugQ XnvUe5vNuigT9nKGLa7a75b0W6ic7g8xHmw82fJz1VvcC3B2/7yCRSZIr4icC/Aq2jC8 IfMXa/kc1cAUtpQQINYzPCF8qbJ3s4amBy7MWyeksXgnXpFHTBjyaQ/RZBiHLZPU5IBE 1MsKMuu5xRhTDTOPdJGrnHyM6QWXdTVPJsrPJS/hbPZFXJPnS7n/0RHbeiSKwSZIXw6/ CNXtAVfcd7k1rw/O0/p9chAI1/IWMmFocxPwO//c4k9qZi9NUK937Spg0FBi9uIE4grI h31g==
X-Gm-Message-State: AOAM531X/QzIfRPU9IKwYZLhETa2Z1U2TzBk0bmeYo4uJ5YR2c1ykN/f biHJZwc8cRfrSfmwmmqGj3qLQgU/RoFZ4gtx9BqYyn3Pi6LD5w==
X-Google-Smtp-Source: ABdhPJyefcWPcghPpChbfgMmcDjkidjQY42ONTGaikmx+vInCXXAcxsLrYxrhWdOnmNg5E4rmz2mCKXMwy3Rtj8+j3E=
X-Received: by 2002:ab0:7499:: with SMTP id n25mr2456895uap.118.1598732926961; Sat, 29 Aug 2020 13:28:46 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <330a76d8-2f05-795f-42a6-01de094b54b4@joelhalpern.com> <BYAPR13MB2437D23542B163D477B583C8D95A0@BYAPR13MB2437.namprd13.prod.outlook.com> <93726585-ccdd-3460-e6c6-540f98ec9084@joelhalpern.com> <BYAPR13MB243700523A1B5D597973C1CCD95A0@BYAPR13MB2437.namprd13.prod.outlook.com> <2265a594-f48f-3903-d998-3bb764df627a@joelhalpern.com> <b7b110ce14344cadb74b80ea9ccce144@huawei.com> <f07c0de8-6d51-7ffe-7ff5-8fb13212708a@joelhalpern.com> <3f563fbf4a3742a195e61d96844bd042@huawei.com> <MN2PR15MB29903640C9630924BA18B61E8F5B0@MN2PR15MB2990.namprd15.prod.outlook.com> <77124c508ce54822a70afc616c31e5cf@att.com> <CAE4dcxnYo8NCB_ADmd-Qv-5ZwZ5hpM4FtgnF=oLcELTO2i7o=w@mail.gmail.com> <5765E489-B949-424B-8217-8049948AFD08@att.com> <CA+YzgTssZ750UXoc0xzCzD63rbbp3uA_4mzasfLMgni1_Z8J+A@mail.gmail.com> <CF569281-FBA6-4A6F-9888-FA61FA423C1A@piuha.net> <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark> <c45ed6dd357842818c5840793cb17f36@huawei.com> <30c835f5ce644ccf8f3568cdccb07b0a@huawei.com> <HE1PR07MB4156650423734880FBB37ADBF0540@HE1PR07MB4156.eurprd07.prod.outlook.com> <a9b7e19b7dac474a8a9355746fadf129@huawei.com> <VI1PR0601MB215756864B9535C3D0E3FA5B9E550@VI1PR0601MB2157.eurprd06.prod.outlook.com> <CABNhwV0F3Zqq_FBU1WbB4sUasc=+OrAuEk1SW_WsHR7rx6LiJA@mail.gmail.com>
In-Reply-To: <CABNhwV0F3Zqq_FBU1WbB4sUasc=+OrAuEk1SW_WsHR7rx6LiJA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 29 Aug 2020 16:28:36 -0400
Message-ID: <CABNhwV1GFQS=NVpoa+m4o3SSogmTkLYq01Hct2XPh5LVowF0ZA@mail.gmail.com>
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, Jari Arkko <jari.arkko@piuha.net>, Jeff Tantsura <jefftant.ietf@gmail.com>, TEAS WG <teas@ietf.org>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000033cc8f05ae0a0423"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Jled9CwteiTF4OapF7oSgqzfD50>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
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, 29 Aug 2020 20:28:52 -0000
Isolation in very basic terms you can think of the two ends of the spectrum dedicated and shared and then you have all the degrees of isolation to get to dedicated which would be the highest cost as far as tier of service. This concept is no different then provisioning optical OTN 100G circuits with path diversity that when provisioning circuits at Layer 1 you don’t any DWDM wavelength to traverse a common pop or path. Kind Regards Gyan On Sat, Aug 29, 2020 at 4:09 PM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > Hi All > > I have been following along on the “isolation” context debate and I agree > with Xuesong and Luis that I think it is important to define the concept of > “isolation” as it pertains to transport slice. > > I agree with Adrian’s comment on transport slice and that the concept of > isolation as a service measurable from a customer point of view and what > they have access to as far as diagnostics as well as delivery isolation > which is an operators point of view of the slice and how transport had been > “sliced” so to speak t create physical or logical isolation. From a > isolation as a service perspective it does not have to be 100% measurable > by the customer as the customer would not have visibility into the provider > network. Does not mean that isolation as a service can not still be > provided by operators at a higher cost to customers. There maybe a way to > provide some transparency to customers so they can see what they are paying > for. > > In basic terms “isolation” I agree is important to be defined as isolation > has many many different meaning and it could mean one thing to an operator > delivering the service and another thing for a customer paying for a higher > tier Enhanced VPN service and so want to understand what they are getting > as far as SLA and how it can be proven and measured from a customer > perspective. > > The reason as well why isolation is critical abstraction layer from a TEAS > traffic steering perspective and why it come up is that from a service > delivery perspective you can steer traffic onto a dedicated path that are > not shard resources and maybe can have “degrees of isolation” as well in > terms of marketing a higher tier SLA to provide that degree of path > isolation by limiting the customers that traverse a traffic engineered > path. Also when you provisioning a higher tier Enhanced VPN and you have > VPN A and VPN B and you provision for path diversity similarly to OTN 100G > P2P wave circuit provisioning process. Their maybe customer parameters as > far as “isolation” and cost for the tiers of isolation that the operators > wants to sell to customers. So complete path isolation meaning dedicated or > a degree of isolation meaning logical isolation and each tier has a > different price point. > > Some of this verbiage is already in the appendix and may just need some > tweaking but I do agree it is an important to keep as part of the > definition. > > Kind Regards > > Gyan > > > > On Thu, Aug 27, 2020 at 6:43 AM LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmurillo@telefonica.com> wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi all, >> >> >> >> >> >> I agree with Xuesong in the fact that we cannot leave the idea of >> isolation open to interpretation. This is precisely the reason why we need >> to have a definition >> >> on it in the context of transport slicing. >> >> >> >> >> >> Best regards >> >> >> >> >> >> Luis >> >> >> >> >> >> >> >> >> >> *De:* Teas <teas-bounces@ietf.org> >> >> *En nombre de *Gengxuesong (Geng Xuesong) >> >> >> *Enviado el:* jueves, 27 de agosto de 2020 4:28 >> >> >> *Para:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Dongjie >> (Jimmy) <jie.dong@huawei.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; >> TEAS WG <teas@ietf.org>; Jari Arkko <jari.arkko@piuha.net> >> >> >> *CC:* Vishnu Pavan Beeram <vishnupavan@gmail.com> >> >> >> *Asunto:* Re: [Teas] WG adoption - >> draft-nsdt-teas-transport-slice-definition - Appendix >> >> >> >> >> >> >> >> >> >> Hi Daniele >> >> >> >> >> >> You have pointed out some technique that may not be necessarily under the >> concept of isolation. >> >> The first one disjointness is used mostly for protection and the second >> one is a dedicated physical link/network for some service. Isolation, in my >> understanding, describes the requirement that the traffic of service won’t >> interfere with each other when they >> >> are transmitted together. These two cases may not be included. >> >> >> And, most importantly, these possible different understanding of this >> concept makes it more >> >> necessary to be clearly defined in the document. >> >> >> >> >> >> Xuesong >> >> >> >> >> >> >> >> >> >> *From:* Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com >> <daniele.ceccarelli@ericsson.com>] >> >> >> >> >> *Sent:* Wednesday, August 26, 2020 9:34 PM >> >> >> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>; Gengxuesong (Geng Xuesong) < >> gengxuesong@huawei.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; >> >> TEAS WG <teas@ietf.org>; Jari Arkko <jari.arkko@piuha.net> >> >> >> *Cc:* Vishnu Pavan Beeram <vishnupavan@gmail.com> >> >> >> *Subject:* RE: [Teas] WG adoption - >> draft-nsdt-teas-transport-slice-definition - Appendix >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> I see different interpretations of isolation and they make me think we >> don’t need it, let me try to explain why. >> >> >> >> >> >> >> >> >> 1. In some cases I see as requirement the fact that a given traffic >> must not share a path with another type of traffic, or a port, or a >> link…that’s >> >> what we commonly call “disjointness”, right? We’ve been speaking >> about SRLG disjointness for decades. >> 2. In some other cases the requirement is not to have any type of >> interference from any type of traffic in the network…that’s a leased line, >> or a dedicated network…we >> >> can’t really speak about network slice there. >> >> >> >> >> >> >> If I got the requirements right, I believe we already have all the cases >> covered. >> >> >> Am I missing any other requirement? >> >> >> >> >> >> BR >> >> >> Daniele >> >> >> >> >> >> >> >> >> >> *From:* Teas <teas-bounces@ietf.org> >> >> *On Behalf Of *Dongjie (Jimmy) >> >> >> *Sent:* den 26 augusti 2020 14:56 >> >> >> *To:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Jeff Tantsura >> <jefftant.ietf@gmail.com>; TEAS WG <teas@ietf.org>; Jari >> >> Arkko <jari.arkko@piuha.net> >> >> >> *Cc:* Vishnu Pavan Beeram <vishnupavan@gmail.com> >> >> >> *Subject:* Re: [Teas] WG adoption - >> draft-nsdt-teas-transport-slice-definition - Appendix >> >> >> >> >> >> >> >> >> >> I also agree with the proposal of the chairs, and think it is important >> to have input from the WG about these terms. >> >> >> >> >> >> >> For isolation, there was some discussion in design team about classifying >> the isolation requirement into different dimensions in the >> >> context of IETF, such as: traffic separation, interference avoidance, >> failure protection, etc., then each can be mapped to corresponding >> mechanisms defined and developed in IETF. >> >> >> >> >> >> >> Perhaps we could follow this way to clarify the meaning of isolation from >> a transport slice point of view, and may find suitable terms >> >> to refer to some specific isolation requirement. >> >> >> >> >> >> Best regards, >> >> >> Jie >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From:* Gengxuesong (Geng Xuesong) >> >> >> >> >> *Sent:* Wednesday, August 26, 2020 10:40 AM >> >> >> *To:* Jeff Tantsura <jefftant.ietf@gmail.com>; TEAS WG <teas@ietf.org>; >> Jari Arkko <jari.arkko@piuha.net> >> >> >> *Cc:* Vishnu Pavan Beeram <vishnupavan@gmail.com> >> >> >> *Subject:* RE: [Teas] WG adoption - >> draft-nsdt-teas-transport-slice-definition - Appendix >> >> >> >> >> >> >> >> >> >> +1 >> >> >> And one more supplementary comment about “Isolation is not a directly >> measurable SLO”. Maybe >> >> here is some fog about what is measurable. Isolation could not described >> by number/value. But it doesn’t mean that it is an abstract concept that >> could not be defined precisely. People are asking whether TE link is >> isolated or not. It could be clarified by >> >> some deep analysis, good discussions and clear text. There is no >> conclusion yet just because we don’t even allow it to be existing in an WG >> document. And I don’t think the definition of other SDOs really matter. >> Because isolation in mobile network is different >> >> from isolation in IETF. If there is requirement in IETF, define it in >> IETF.. We can’t say we could not get to somewhere because there is no >> path.. Build the path by ourselves. >> >> >> >> >> >> >> Xuesong >> >> >> >> >> >> >> >> >> >> *From:* Teas [mailto:teas-bounces@ietf.org <teas-bounces@ietf.org>] >> >> *On Behalf Of *Jeff Tantsura >> >> >> *Sent:* Wednesday, August 26, 2020 6:32 AM >> >> >> *To:* TEAS WG <teas@ietf.org>; Jari Arkko <jari.arkko@piuha....net >> <jari.arkko@piuha.net>> >> >> >> *Cc:* Vishnu Pavan Beeram <vishnupavan@gmail.com> >> >> >> *Subject:* Re: [Teas] WG adoption - >> draft-nsdt-teas-transport-slice-definition - Appendix >> >> >> >> >> >> >> >> >> >> >> >> >> >> I find Pavan and Lou proposal reasonable and a good/working way forward. >> >> >> While isolation is not a directly measurable SLO, it is often a legally >> binding requirement wrt service provided, could be expressed as a physical >> SRLG or disjointness. >> >> >> It is also a viable constrain to be used in a path computation logic. >> >> >> There are connectivity RFIs that explciteily require full physical >> separation/isolation - finance for security reasons, DCI for resiliency, >> etc. >> >> >> >> >> >> We could pretend it doesn’t exist (which is the complete removal) or >> find an appropriate and acceptable to the WG description as the document >> evolves. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> Jeff >> >> >> >> >> >> >> >> >> >> >> On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <jari.arkko@piuha.net>, >> wrote: >> >> >> >> >> High-level bit: I would like to see the document adopted. With changes if >> needed. Let the WG decide. Design teams are there just for preparing >> proposals. Authority to do stuff is entirely in the >> >> WG now. >> >> >> >> >> >> When it comes to the isolation topic, however, FWIW, I wanted to provide >> both a context from design team discussions and my personal perspective on >> this. >> >> >> >> >> >> Design team discussions: >> >> >> >> >> >> We’ve had variants of this discussion on almost all of the calls we’ve >> had for the last year. One one side there was our shared observation that >> industry uses the term isolation, and (perhaps less widely shared >> >> conclusion) that it is important to be able to relate to this. On the >> other side, there was our shared agreement that what matters from a >> requirement perspective is the bandwidth and other requirements, and that >> there are several techniques that can provide >> >> the desired characteristic of not having your neighbour affect the >> bandwidth the service provider has agreed to give you. >> >> >> >> >> >> The text that we had was in an appendix precisely because we felt that >> the top-level SLOs should be the requirement and are sufficient by >> themselves. The appendix only attempts to say that >> >> “there’s multiple ways to achieve this, and by the way, this term in the >> industry relates to our work in this indirect way”.... >> >> >> >> >> >> I can appreciate that we may have failed in the task of writing that. >> Delete and move on, no biggie :-) >> >> >> >> >> >> Personal perspective: >> >> >> >> >> >> My impression of customer requirements and how they get represented >> matches with what Joel has been saying in this thread. >> >> >> >> >> >> I’m fine removing the appendix. >> >> >> >> >> >> If I had my way, I would write the document based entirely on the primary >> characteristics >> >> — such as that we promise you n GB/s. Then I would write a footnote or >> appendix somewhere that explains that this notion isolation has also been >> discussed elsewhere, and that it can be represented using the primary >> characteristics, >> >> and hence need not be discussed further in this document. One could >> perhaps also point out that there are multiple ways to implement the >> primary characteristics promises, so that those promises can be kept >> despite what’s happening >> >> with your neighbour’s traffic. And leave it at that. But I understand >> from this thread that people are reluctant to do that, and may even be >> reluctant to write anything about isolation. I’m fine with that, >> >> too. >> >> >> >> >> >> Jari >> >> >> >> >> >> _______________________________________________ >> >> >> Teas mailing list >> >> >> Teas@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/teas >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, >> puede contener información privilegiada o confidencial y es para uso >> exclusivo de la persona o entidad de destino. Si no es usted. el >> destinatario indicado, queda notificado de que la >> >> lectura, utilización, divulgación y/o copia sin autorización puede estar >> prohibida en virtud de la legislación vigente. Si ha recibido este mensaje >> por error, le rogamos que nos lo comunique inmediatamente por esta misma >> vía y proceda a su destrucción. >> >> >> >> >> >> The information contained in this transmission is privileged and >> confidential information intended only for the use of the individual or >> entity named above. If the reader of this message is not the intended >> recipient, you are hereby notified that any dissemination, >> >> distribution or copying of this communication is strictly prohibited. If >> you have received this transmission in error, do not read it. Please >> immediately reply to the sender that you have received this communication >> in error and then delete it. >> >> >> >> >> >> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> destinatário, pode conter informação privilegiada ou confidencial e é para >> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o >> destinatário indicado, fica notificado de que a >> >> leitura, utilização, divulgação e/ou cópia sem autorização pode estar >> proibida em virtude da legislação vigente. Se recebeu esta mensagem por >> erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e >> proceda a sua destruição >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Daniele Ceccarelli
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- [Teas] WG adoption - draft-nsdt-teas-transport-sl… Vishnu Pavan Beeram
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Vishnu Pavan Beeram
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jari Arkko
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jeff Tantsura
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Young Lee
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Uma Chunduri
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… mohamed.boucadair
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Eric Gray
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… mohamed.boucadair
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… John E Drake
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Igor Bryskin
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jeff Tantsura
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Eric Gray
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… John E Drake
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Igor Bryskin
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Vishnu Pavan Beeram