Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Greg Mirsky <gregimirsky@gmail.com> Fri, 21 August 2020 23:21 UTC

Return-Path: <gregimirsky@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 A1E1F3A1443 for <teas@ietfa.amsl.com>; Fri, 21 Aug 2020 16:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 WIiiQmjcdGVM for <teas@ietfa.amsl.com>; Fri, 21 Aug 2020 16:21:28 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 A0E3F3A143E for <teas@ietf.org>; Fri, 21 Aug 2020 16:21:27 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id y26so1422118lfe.2 for <teas@ietf.org>; Fri, 21 Aug 2020 16:21:27 -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=Z1vdhUz1oMnEZaFebB9k8xTotYnR0XK8KC595ITbL2U=; b=PQ3K+fgSMj8HcDBX6IlREkTloUJFXPCNA9SUn3HNtow3dDtiCHZ/rjJd8N0Fs1Y1P/ NV2v+V74zO4KdUZj20EGZfyLDGhNPE+mC8aAzaRfE6IqKUpZHBn+Z8pFETt1NSqbtmSA LONHnDWFapmRNIR5AzUQ1kgssuGfLs053YvlS4dwY2kl/avvxFWoyIncgcz/Z+oYaDjA WhXYwegptta/JPCx89dX73tWGHkj1VIoaosQkFIGX5DLEIqco8wA/5VtJiXQ/PCs1Ege pU3SkmAnNOAu060kR5w+zaiI3BHfaIVjvKVctpsrr5yrIsGWKIwWfrbCR/8+3klMrIhw TC6A==
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=Z1vdhUz1oMnEZaFebB9k8xTotYnR0XK8KC595ITbL2U=; b=n1CjCDviNB7H7qzrCNU6NmOmO5sMicLQy0IG15Lah+/QRR+LSzQZweNdT6izzC5aix lnB09qw+w5aIs24csm695tTX1ToRXiKSsHzT+cSqJ9WXBFMLlVNOGuJdT+dAdObQCeTT Pyats59csJeOLo93kjSXhOItkPs0X0himp5HMweyDHMg4WzvDl8ZHw3bYBW+x/TYcg5f osL7iOZOvlFQR5TA56WLEgm5nXcOjvmrrPOzPOehnMNTV4b9ckpVaoYvXYujCeTcQphN G9KjfpzYc/WaTXb2zXvzdEDMBjq7iVyI6NR1/t+JmqOgEBncKHGDfAy/UxGtKOh9BWFl tYgg==
X-Gm-Message-State: AOAM532o6pqd2hK0/+P6mApSlJvdaSvTI/XuqT0QCuqu+3sxbPm2hBx9 n3jhXgwhyHsJ1de7dPoleEWraTo8wMvHAJNVV0c=
X-Google-Smtp-Source: ABdhPJxSCf2kqI2CfiU9EV1R1NmWYFG5Fp/h0L9U6Ix+jF1le2X3xXmMysRTKoEJwFzlR0q7GRB9LNc3q0Kta3QQfZ0=
X-Received: by 2002:a19:be53:: with SMTP id o80mr2445518lff.33.1598052085398; Fri, 21 Aug 2020 16:21:25 -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> <CAE4dcxniwa35hmV81XwEU6uR_E2ZFyUmAyLumV6RJ_ZN+C0DhQ@mail.gmail.com> <ef4c124a-7e61-cbca-88f5-a874a0118f51@joelhalpern.com> <BYAPR13MB243709886A56D6D295DE1770D95B0@BYAPR13MB2437.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB243709886A56D6D295DE1770D95B0@BYAPR13MB2437.namprd13.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 21 Aug 2020 16:21:14 -0700
Message-ID: <CA+RyBmWfXo8-yaEYget8L7aArcRO2A+MfKVtPsD79Sg3JE=qvA@mail.gmail.com>
To: Kiran Makhijani <kiranm@futurewei.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "Luis M. Contreras" <contreras.ietf@gmail.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2011505ad6b7e69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8_2HGWiJcpxS90C9ypHWhU2U72o>
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: Fri, 21 Aug 2020 23:21:33 -0000

Hi Kiran,
I have to admit that I'm confused by the last paragraph in your note.
First, you agree that isolation interpreted is not observable (though I am
not sure what quote marks around directly signify). But then you add "will
rely on other means of monitoring". Isn't any type of monitoring, in fact,
a method of a direct observation?
Also, I sense that one of the motivations behind using the term isolation
is to differentiate between physical and virtual instances that provide a
service, e.g., physical link vs. a link in the overlay network. If that is
the case, perhaps we can avoid the contention around the use of the term
isolation as SLO and instead add a parameter that can have two values,
physical and virtual?

Regards,
Greg

On Fri, Aug 21, 2020 at 3:53 PM Kiran Makhijani <kiranm@futurewei.com>
wrote:

> Hi Joel,
> Looks like your main concern is that text seem to say that isolation is
> observable.
>
> That's not the intent. We just wanted to scope 'isolation' with in the
> context of transport slices not define it. During IETF 107 you gave a
> feedback that isolation is not directly observable, and we all completely
> agreed, dropped a lot of text accordingly.
>
> In this text, the important piece is to capture that customer could also
> be very specific about asking "my traffic should be separated from (or
> should have no interference with) other traffic".
> This is not covered in the document and without such clarification, we
> cannot scope NBI properly. I was thinking if we define 'isolation' then
> that can be a container in NBI. One common use case where customer could
> ask this is financial institutions or critical infrastructure explicitly
> asking for a (or a set of) physical ports or links.
>
> The last para simply says there are 3 related things that customer could
> explicitly ask for (termed as 'isolation') and when realizing transport
> slices operators could possibly do so & so to meet those asks.
>
> An alternative to deleting the text maybe  - don’t use term isolation but
> describe explicit requirement of traffic separation. And maybe clearly say
> this is not 'directly' observable and will rely on other means of
> monitoring that are case specific such as mapping physical port counters to
> service counters etc.
>
> -Kiran
>
> > -----Original Message-----
> > From: Joel M. Halpern <jmh@joelhalpern.com>
> > Sent: Friday, August 21, 2020 8:42 AM
> > To: Luis M. Contreras <contreras.ietf@gmail.com>om>; Dongjie (Jimmy)
> > <jie.dong@huawei.com>
> > Cc: Kiran Makhijani <kiranm@futurewei.com>om>; Vishnu Pavan Beeram
> > <vishnupavan@gmail.com>om>; TEAS WG <teas@ietf.org>rg>; LUIS MIGUEL
> > CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
> > Subject: Re: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition -
> > Appendix
> >
> > Luis, I think I disagree with you.
> > Not of course, about the question of whether operators care about
> isolation
> > properties.
> > But about whether it belongs in this document.
> >
> > I am quite sure that when designing services for customers, you and your
> team
> > worry about many forms of isolation.  Many of which do not appear in the
> > eventual SLA (even if they do occur in informal discussion).  And many
> of which
> > do not appear as explicit parameters on any of the interfaces.
> >
> > The authors attempted t provide an observable definition of isolation.
> > They were not able to do so.  The text they now have tries to claim
> utility,
> > claims relevance to the customer, but is not actually usable in
> designing a
> > service.
> >
> > "Isolation" as a network property probably is actually many different
> > properties.  For example, a bandwidth commitment (which we do have in the
> > definitions) is a form of isolation.  A delay variation commitment is a
> form of
> > isolation.  But as a term on its own, separate from these parameters,
> "isolation"
> > does not add value to this document.
> >
> > Also remember that no document we produce will be or can bee complete.
> > We produce useful pieces.  You put them together.  As an operator you add
> > your many constraints, your customers goals and constraints, and you
> build and
> > deliver service.
> >
> > Yours,
> > Joel
> >
> > On 8/21/2020 4:49 AM, Luis M. Contreras wrote:
> > > Hi Jie, Joel, all,
> > >
> > > Just to share my view. The idea of isolation is intrinsically related
> > > to the notion of slice in the industry, and as such it should be
> > > covered in the definitions draft when referring to transport slices.
> > >
> > > The development of what isolation implies, in practical terms, could
> > > go to the framework draft or to any other specific document, and for
> > > sure we can expect references to degrees of isolation achieved in the
> > > mapping of slicing mechanisms to distinct transport technologies
> > > through the SBI of the TSC.
> > >
> > > Not covering isolation at all, basically makes the work on transport
> > > slicing incomplete from an operator’s perspective.
> > >
> > > In that sense I support keeping the text on isolation (as an annex or
> > > in the main part of the document). For sure the text can be always
> > > improved, but as it is now is a sufficiently generic definition to
> > > facilitate the development of its scope when applied to transport
> > > slicing in any other document.
> > >
> > > Best regards,
> > >
> > > Luis
> > >
> > >
> > > El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy)
> > > (<jie.dong@huawei.com
> > > <mailto:jie.dong@huawei.com>>) escribió:
> > >
> > >     Hi Joel,
> > >
> > >     Thanks for your clarification about the procedure.
> > >
> > >     What I meant is to provide some background about the design team's
> > >     discussion, which may help the WG to review and give comments on
> > >     this draft. Of course the decision will be made by the WG.
> > >
> > >     One of the reasons of keeping the isolation discussion in this
> draft
> > >     is that isolation has been considered as one of the characteristics
> > >     of network slicing in most of the related standards and
> > >     publications, and it would be incomplete if the definition draft
> > >     does not touch this. And in IETF history isolation has been
> > >     considered as one requirement of VPNs, the discussion is necessary
> > >     for explaining the relationship and difference between network
> slice
> > >     and VPNs. Also note that in the last paragraph of the appendix, it
> > >     tries to separate the requirements on isolation from several
> > >     possible realization mechanism, which makes this description
> > >     reasonably generic.
> > >
> > >     Best regards,
> > >     Jie
> > >
> > >
> > >      > -----Original Message-----
> > >      > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com
> > >     <mailto:jmh.direct@joelhalpern.com>]
> > >      > Sent: Friday, August 21, 2020 11:28 AM
> > >      > To: Dongjie (Jimmy) <jie.dong@huawei.com
> > >     <mailto:jie.dong@huawei.com>>; Kiran Makhijani
> > >      > <kiranm@futurewei.com <mailto:kiranm@futurewei.com>>; Vishnu
> > >     Pavan Beeram
> > >      > <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>; TEAS WG
> > >     <teas@ietf.org <mailto:teas@ietf.org>>
> > >      > Subject: Re: [Teas] WG adoption -
> > >     draft-nsdt-teas-transport-slice-definition -
> > >      > Appendix
> > >      >
> > >      > The consensus of the design team is relevant as a recommendation
> > >     to the
> > >      > WG, but otherwise is not relevant for whether the WG should
> > >     agree.  In
> > >      > terms of WG adoption, the design team draft has the same status
> > >     as any
> > >      > other individual draft. The WG comes to its conclusion.
> > >      >
> > >      > There is no obligation for the WG to retain the text from the
> > >     appendix
> > >      > anywhere.  In particular, the WG is under no obligation to
> retain
> > >     the last
> > >      > paragraph of the appendix anywhere.
> > >      >
> > >      > I have not seen any good argument for retaining the text.  It
> > >     does not seem
> > >      > to add to or even fit with the purpose of the definitions draft.
> > >      > If anything, it is confusing at it seems to say "this is not a
> > >     parameter / this is
> > >      > a parameter"
> > >      >
> > >      > Yours,
> > >      > Joel
> > >      >
> > >      > On 8/20/2020 11:17 PM, Dongjie (Jimmy) wrote:
> > >      > > Hi Joel,
> > >      > >
> > >      > > In the design team there were several rounds of discussion
> > >     about the
> > >      > content in the appendix and where it should be placed. The
> > >     current text in
> > >      > the appendix reflects the consensus of the design team,
> although some
> > >      > minor edits were not included yet.
> > >      > >
> > >      > > As for whether some of the text in appendix will be moved to
> the
> > >      > framework document, currently the design team has no specific
> opinion
> > >      > about this, and feedbacks from WG are appreciated. While as
> Kiran
> > >      > mentioned, description and discussion about isolation is needed
> > >     in the NS-DT
> > >      > documents.
> > >      > >
> > >      > > Best regards,
> > >      > > Jie
> > >      > >
> > >      > >> -----Original Message-----
> > >      > >> From: Teas [mailto:teas-bounces@ietf.org
> > >     <mailto:teas-bounces@ietf.org>] On Behalf Of Joel M.
> > >      > >> Halpern
> > >      > >> Sent: Friday, August 21, 2020 7:00 AM
> > >      > >> To: Kiran Makhijani <kiranm@futurewei.com
> > >     <mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram
> > >      > >> <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>; TEAS
> > >     WG <teas@ietf.org <mailto:teas@ietf.org>>
> > >      > >> Subject: Re: [Teas] WG adoption -
> > >      > >> draft-nsdt-teas-transport-slice-definition - Appendix
> > >      > >>
> > >      > >> Since I do not think that the material in the appendix is
> > >     useful, I
> > >      > >> for one will not push for adding it to the Framework.  You
> are
> > >      > >> welcome to dabate adding it to the framework with the rest of
> > >     the WG.
> > >      > >> But it does not belong in the definitions draft.
> > >      > >>
> > >      > >> Yours,
> > >      > >> Joel
> > >      > >>
> > >      > >> On 8/20/2020 5:20 PM, Kiran Makhijani wrote:
> > >      > >>> Hi Joel,
> > >      > >>> I am ok to remove some part from Appendix only if it is
> > >     included in
> > >      > >>> the
> > >      > >> framework first.
> > >      > >>>
> > >      > >>> But for the TSRE, I have proposed clearer and shorter text
> > >     that they
> > >      > >>> are not
> > >      > >> visible to the consumer of a transport slices. One of the
> > >     purpose of
> > >      > >> definitions document is 'define' common terminology in the
> > >     scope of
> > >      > >> transport slices, and all we are saying is that when
> realizing a
> > >      > >> transport slice, things TSEs will map to are called TSREs.
> > >      > >>> I am not able to see the drawback of saying so.
> > >      > >>>
> > >      > >>> Thanks
> > >      > >>> Kiran
> > >      > >>>
> > >      > >>>> -----Original Message-----
> > >      > >>>> From: Joel Halpern Direct <jmh.direct@joelhalpern.com
> > >     <mailto:jmh.direct@joelhalpern.com>>
> > >      > >>>> Sent: Thursday, August 20, 2020 1:19 PM
> > >      > >>>> To: Kiran Makhijani <kiranm@futurewei.com
> > >     <mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram
> > >      > >>>> <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>;
> > TEAS
> > >     WG <teas@ietf.org <mailto:teas@ietf.org>>
> > >      > >>>> Subject: Re: [Teas] WG adoption -
> > >      > >>>> draft-nsdt-teas-transport-slice-definition
> > >      > >>>>
> > >      > >>>> No, your replies did not in any way address my concerns.
> > >      > >>>>
> > >      > >>>> I would suggest removing the references to TSRE and more
> > >      > >>>> importantly removing appendix A.1, or at least the last
> part
> > >     of the
> > >      > appendix.
> > >      > >>>>
> > >      > >>>> Yours,
> > >      > >>>> Joel
> > >      > >>>>
> > >      > >>>> On 8/20/2020 2:54 PM, Kiran Makhijani wrote:
> > >      > >>>>> Hi Joel,
> > >      > >>>>> After having replied to your comments, we have not heard
> > >     further
> > >      > >>>>> if they
> > >      > >>>> were convincing.
> > >      > >>>>> Please let us know.
> > >      > >>>>> Thanks
> > >      > >>>>> Kiran
> > >      > >>>>>
> > >      > >>>>>> -----Original Message-----
> > >      > >>>>>> From: Teas <teas-bounces@ietf.org
> > >     <mailto:teas-bounces@ietf.org>> On Behalf Of Joel M. Halpern
> > >      > >>>>>> Sent: Wednesday, August 19, 2020 9:04 AM
> > >      > >>>>>> To: Vishnu Pavan Beeram <vishnupavan@gmail.com
> > >     <mailto:vishnupavan@gmail.com>>; TEAS WG
> > >      > >>>>>> <teas@ietf.org <mailto:teas@ietf.org>>
> > >      > >>>>>> Subject: Re: [Teas] WG adoption -
> > >      > >>>>>> draft-nsdt-teas-transport-slice-definition
> > >      > >>>>>>
> > >      > >>>>>> Without repairs to the issues I have raised on the email
> > >     list, I
> > >      > >>>>>> do not think this document should be adopted as a WG
> > document.
> > >      > >>>>>> We are close, but not quite there.
> > >      > >>>>>>
> > >      > >>>>>> Yours,
> > >      > >>>>>> Joel
> > >      > >>>>>>
> > >      > >>>>>> On 8/19/2020 11:50 AM, Vishnu Pavan Beeram wrote:
> > >      > >>>>>>> All,
> > >      > >>>>>>>
> > >      > >>>>>>> This is start of a *three* week poll on making
> > >      > >>>>>>> draft-nsdt-teas-transport-slice-definition-03 a TEAS
> working
> > >      > >>>>>>> group
> > >      > >>>>>> document.
> > >      > >>>>>>> Please send email to the list indicating "yes/support"
> or
> > >     "no/do
> > >      > >>>>>>> not support". If indicating no, please state your
> > >     reservations
> > >      > >>>>>>> with the document. If yes, please also feel free to
> provide
> > >      > >>>>>>> comments you'd like to see addressed once the document
> is
> > >     a WG
> > >      > >> document.
> > >      > >>>>>>>
> > >      > >>>>>>> The poll ends September 9th (extra week to account for
> > >     vacation
> > >      > >> season).
> > >      > >>>>>>>
> > >      > >>>>>>> Thanks,
> > >      > >>>>>>> Pavan and Lou
> > >      > >>>>>>>
> > >      > >>>>>>> _______________________________________________
> > >      > >>>>>>> Teas mailing list
> > >      > >>>>>>> Teas@ietf.org <mailto:Teas@ietf.org>
> > >      > >>>>>>>
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >      > w.
> > >      > >>>>>>>
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      > ietf.org
> > >
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> > 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
> > eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
> > ta=02%7C01%7Ckiranm%40
> > >      > f
> > >      > >>>>>> utur
> > >      > >>>>>>>
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      > ewei.com
> > >
> > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea174
> > 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
> > 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
> > G%2BmbpcA%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d84459a35
> > 1%7C0fee8ff2a3b24018
> > >      > 9
> > >      > >>>>>> c753a1d
> > >      > >>>>>>>
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
> > >      > 2B
> > >      > >>>>>> RAlZTXBv5
> > >      > >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
> > >      > >>>>>>>
> > >      > >>>>>>
> > >      > >>>>>> _______________________________________________
> > >      > >>>>>> Teas mailing list
> > >      > >>>>>> Teas@ietf.org <mailto:Teas@ietf.org>
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >      > w
> > >      > >>>>>> .i
> > >      > >>>>
> > >      > >>
> > >      > etf.org
> > >
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org
> > %2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> > 7336213276038270&amp;sdata=He3XPdNABefXKOz92Z0QYR2Va2KIe43lclCTD7
> > 12p5M%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02
> > %7C01%7Ckiranm%40f
> > >      > u
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      > turewei.com
> > >
> > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturew
> > ei.com%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea
> > 1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> > %7C637336213276038270&amp;sdata=7PuKdwn1Yyw9PIxiIfj62%2Bya%2FBPG
> > fkCKgMnpTNbtAPs%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d844
> > 59a351%7C0fee8ff2a3b24
> > >      > 01
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
> > >      > G
> > >      > >>>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
> > >      > 0
> > >      > >>>>>
> > >      > >>>>> _______________________________________________
> > >      > >>>>> Teas mailing list
> > >      > >>>>> Teas@ietf.org <mailto:Teas@ietf.org>
> > >      > >>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >      > w.
> > >      > >>>>>
> > >      > >>>>
> > >      > >>
> > >      > ietf.org
> > >
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> > 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
> > eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
> > ta=02%7C01%7Ckiranm%40
> > >      > f
> > >      > >>>> utur
> > >      > >>>>>
> > >      > >>>>
> > >      > >>
> > >      > ewei.com
> > >
> > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea174
> > 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
> > 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
> > G%2BmbpcA%3D&amp;reserved=0>%7C7bb861e35ac84653b62208d8454659a
> > c%7C0fee8ff2a3b24018
> > >      > 9
> > >      > >>>> c753a1d
> > >      > >>>>>
> > >      > >>>>
> > >      > >>
> > >      >
> > 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
> > >      > BL
> > >      > >>>> sLRq9T9a
> > >      > >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
> > >      > >>>>>
> > >      > >>
> > >      > >> _______________________________________________
> > >      > >> Teas mailing list
> > >      > >> Teas@ietf.org <mailto:Teas@ietf.org>
> > >      > >>
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> > etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> > urewei.com%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
> > 753a1d5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGP
> > WZBvHzDObgm3N64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
> > >     _______________________________________________
> > >     Teas mailing list
> > >     Teas@ietf.org <mailto:Teas@ietf.org>
> > >
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > >
> > ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> > ur
> > >
> > ewei.com%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
> > 3a1d
> > >
> > 5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGPWZBvHz
> > DObgm3N
> > > 64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
> > >
> > >
> > >
> > > --
> > > ___________________________________________
> > > Luis M. Contreras
> > > contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com>
> > > luismiguel.contrerasmurillo@telefonica.com
> > > <mailto:luismiguel.contrerasmurillo@telefonica.com>
> > > Global CTIO unit / Telefonica
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>