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

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi WG,

Resource reservation/allocation is very important for SLA guarantee. A service without dedicated resource could be queued up/dropped in the network, even if it uses the highest priority, considering that the network resource couldn’t be unlimited.
So I support to add proper descriptions about resource reservation/allocation in  draft-nsdt-teas-transport-slice-definition.
Also, resource allocation is one of the key technologies in DetNet, which is described in RFC8557(Deterministic Networking Problem Statement) and RFC8655(Deterministic Networking Architecture). Maybe the following text could be considered as reference[*][**].

Best Regards
Xuesong

----
[*] RFC rfc8557 section 2 (https://tools.ietf.org/html/rfc8557)
2<https://tools.ietf.org/html/rfc8557#section-2>.  On Deterministic Networking
…
   Reserving resources before packet transmission is the one fundamental
   shift in the behavior of network applications that is impossible to
   avoid.  In the first place, a network cannot deliver finite latency
   and practically zero packet loss to an arbitrarily high offered load.
   Secondly, achieving practically zero packet loss for unthrottled
   (though bandwidth-limited) flows means that bridges and routers have
   to dedicate buffer resources to specific flows or classes of flows.
   The requirements of each reservation have to be translated into the
   parameters that control each host's, bridge's, and router's queuing,
   shaping, and scheduling functions and delivered to the hosts,
   bridges, and routers.

[**] RFC8655 section 3.2.1 (https://tools.ietf.org/html/rfc8655#section-3.2.1)
3.2.1<https://tools.ietf.org/html/rfc8655#section-3.2.1>.  Resource Allocation
3.2.1.1<https://tools.ietf.org/html/rfc8655#section-3.2.1.1>.  Eliminate Contention Loss
   The primary means by which DetNet achieves its QoS assurances is to
   reduce, or even completely eliminate, packet loss due to output
   packet contention within a DetNet node as a cause of packet loss.
   This can be achieved only by the provision of sufficient buffer
   storage at each node through the network to ensure that no packets
   are dropped due to a lack of buffer storage.  Note that App-flows are
   generally not expected to be responsive to implicit [RFC2914<https://tools.ietf.org/html/rfc2914>] or
   explicit congestion notification [RFC3168<https://tools.ietf.org/html/rfc3168>].

   Ensuring adequate buffering requires, in turn, that the source and
   every DetNet node along the path to the destination (or nearly every
   node; see Section 4.3.3<https://tools.ietf.org/html/rfc8655#section-4.3.3>) be careful to regulate its output to not
   exceed the data rate for any DetNet flow, except for brief periods
   when making up for interfering traffic.  Any packet sent ahead of its
   time potentially adds to the number of buffers required by the next-
   hop DetNet node and may thus exceed the resources allocated for a
   particular DetNet flow.  Furthermore, rate limiting (e.g., using
   traffic policing) and shaping functions (e.g., shaping as defined in
   [RFC2475<https://tools.ietf.org/html/rfc2475>]) at the ingress of the DetNet domain must be applied.  This
   is needed for meeting the requirements of DetNet flows as well as for
   protecting non-DetNet traffic from potentially misbehaving DetNet
   traffic sources.  Note that large buffers have some issues (see,
   e.g., [BUFFERBLOAT<https://tools.ietf.org/html/rfc8655#ref-BUFFERBLOAT>]).

   The low-level mechanisms described in Section 4.5<https://tools.ietf.org/html/rfc8655#section-4.5> provide the
   necessary regulation of transmissions by an end system or DetNet node
   to provide resource allocation.  The allocation of the bandwidth and
   buffers for a DetNet flow requires provisioning.  A DetNet node may
   have other resources requiring allocation and/or scheduling that
   might otherwise be over-subscribed and trigger the rejection of a
   reservation.
3.2.1.2<https://tools.ietf.org/html/rfc8655#section-3.2.1.2>.  Jitter Reduction
   A core objective of DetNet is to enable the convergence of sensitive
   non-IP networks onto a common network infrastructure.  This requires
   the accurate emulation of currently deployed mission-specific
   networks, which, for example, rely on point-to-point analog (e.g.,
   4-20mA modulation) and serial-digital cables (or buses) for highly
   reliable, synchronized, and jitter-free communications.  While the
   latency of analog transmissions is basically the speed of light,
   legacy serial links are usually slow (in the order of Kbps) compared
   to, say, Gigabit Ethernet, and some latency is usually acceptable.
   What is not acceptable is the introduction of excessive jitter, which
   may, for instance, affect the stability of control systems.

   Applications that are designed to operate on serial links usually do
   not provide services to recover the jitter, because jitter simply
   does not exist there.  DetNet flows are generally expected to be
   delivered in order, and the precise time of reception influences the
   processes.  In order to converge such existing applications, there is
   a desire to emulate all properties of the serial cable, such as clock
   transportation, perfect flow isolation, and fixed latency.  While
   minimal jitter (in the form of specifying minimum, as well as
   maximum, end-to-end latency) is supported by DetNet, there are
   practical limitations on packet-based networks in this regard.  In
   general, users are encouraged to use a combination of:

   *  Sub-microsecond time synchronization among all source and
      destination end systems, and

   *  Time-of-execution fields in the application packets.

   Jitter reduction is provided by the mechanisms described in
   Section 4.5<https://tools.ietf.org/html/rfc8655#section-4.5> that also provide resource allocation.



From: Teas [mailto:[e-mail]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, August 25, 2020 1:46 AM
To: BRUNGARD, DEBORAH A <[e-mail]>
Cc: Joel Halpern Direct <[e-mail]>; Luis M. Contreras <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; Kiran Makhijani <[e-mail]>; David Sinicrope <david.sinicrope=[e-mail]>; TEAS WG <[e-mail]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

WG,

Thanks to everyone who weighed in on the discussion on the adoption call so far.

WRT the appendix and terminology:

Based on this discussion and the focus of this draft, i.e., definition(s),  our recommendations for the authors are as follows:

  *   Add placeholders in the main text for definitions from a transport network slice point of view:

     *   Isolation
     *   Network resources (shared vs dedicated)
        (Note: we believe it is important for the WG to get consensus on these terms, so just placeholders for now.)

  *   Remove the Appendix

The text on solution aspects (how the slice is realized) should not be in this document.

Given that the adoption poll will run till September 9th, we think it would be helpful to have these changes made ASAP so that  the above changes can be discussed as part of the  adoption call.

Regards,
-Pavan and Lou

On Sat, Aug 22, 2020 at 2:24 PM BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>> wrote:
Hi Luis,

Not sure if you are saying isolation or the appendix example “dedicated resources” needs to stay in the draft?

It is the appendix which I am saying needs to be removed as the term has no meaning. Can a dedicated resource be a TE link? It has defined properties e.g. bandwidth. It is an IETF term.

Isolation also needs to be better defined so we can understand the term - Can you find a reference - 3GPP? As I noted, ETSI references 3GPP, and dedicated resources is not a property of isolation. Does a TE link provide isolation?

Yes, this is just an adoption call, but if it defines isolation as dedicated resources, this document is more appropriately done in SG15 for a single layer “transport” technology network. We need to sort out definitions/examples appropriate for IETF technologies.

Thanks,
Deborah
(individual)
Sent from my iPhone


On Aug 22, 2020, at 2:13 PM, Luis M. Contreras <[e-mail]<mailto:[e-mail]>> wrote:

Hi Deborah,

as you comment, there are different views from different SDOs on isolation. But we lack our own view in IETF. This is precisely the reason why we should include a preliminary definition on the definitions draft that could be further elaborated in the framework document or in any other.

For sure, text is (should be) reviewed up to the point of reaching certain consensus. In fact the current text was hardly debated, amended and discussed during the design team calls (one per week). Again, probably requires more views as the ones in this thread. I think this reflects, in fact, the importance of keeping it in the definition draft.

Best regards

Luis

El vie., 21 ago. 2020 a las 17:52, BRUNGARD, DEBORAH A (<[e-mail]<mailto:[e-mail]>>) escribió:
Hi,

(speaking as an individual)

While the document is in it’s early stages, I think it is important to sort out this use of the term “isolation”. Already by use of the term “transport”, the scope of this work may be confused with the traditional definition of a transport network and overlapping with ITU-T SG15’s transport technologies. Important is to define “transport” carefully for the IETF context, which I think this document is a good start. Mixing “isolation” with “dedicated resources” is a step back to the traditional definition.

As the authors note, the term “isolation” is used in other SDOs, including 3GPP, but it is used differently. Here’s a recent publicly available white paper from ETSI NFV which summarizes the requirements from 3GPP for network slicing:
https://www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-EVE012v030101p.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_NFV-2DEVE_001-5F099_012_03.01.01-5F60_gr-5FNFV-2DEVE012v030101p.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=whW6wCobCa_-nytdz17CmIM40MsdkhU4HeVJS4I_bsE&e=>

In this ETSI document, when they discuss isolation properties, physical resources are not mentioned, they discuss performance, resiliency, security, privacy and management. 3GPP recognizes resources may be logical or physical (and either fully or partly), it is not a “requirement”. Physical and virtual resources are used with respect to “realize”, not define.

I agree with Joel and Dave, I think Appendix A’s example saying a customer will request “dedicated resources” and saying the solution of using dedicated resources (vs. VPN)  guarantees the requirements are met, clashes with the rest of the document (section 5.3 and section 6) which carefully defines resources not as defining a slice but for realizing a slice. Maybe the authors intended it to be an example, but it is too confusing in the context of this document to mix the definition of “isolation” with “dedicated resources”. While an Appendix, it should not clash with the main document. Best is to remove for now.

Thanks,
Deborah
(individual)

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of David Sinicrope
Sent: Friday, August 21, 2020 9:11 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Joel Halpern Direct <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Jie,
You note “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.”

I’m not sure where this is coming from. Do you have references to support these claims?  I’m specifically referring to the claim that “most” related standards and publications consider isolation as a characteristic.  This has not been my experience at all over the last 3 decades including the history of the IETF.

If anything the history of work on VPNs deals with identification of the traffic associated with the VPN not its isolation. Any treatment or characteristic of that traffic has been a function of QoS.

Isolation, in my experience, has not been part of the discussion or texts until the introduction of network slicing and only introduced by a subset of the community.

I agree the text on isolation is confusing and not needed.  I also ask that it be removed.

Thanks,
Dave


________________________________
From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 21, 2020 4:26 AM
To: Joel Halpern Direct; Kiran Makhijani; Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

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:[e-mail]]
> Sent: Friday, August 21, 2020 11:28 AM
> To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani
> <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
> 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 teh 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:[e-mail]] On Behalf Of Joel M.
> >> Halpern
> >> Sent: Friday, August 21, 2020 7:00 AM
> >> To: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> >> <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
> >> 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 <[e-mail]<mailto:[e-mail]>>
> >>>> Sent: Thursday, August 20, 2020 1:19 PM
> >>>> To: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram
> >>>> <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
> >>>> 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 <[e-mail]<mailto:[e-mail]>> 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
> >>>>>> <[e-mail]<mailto:[e-mail]>>
> >>>>>> 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
> >>>>>>> [e-mail]<mailto:[e-mail]>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=7d132922-23b3ea8b-7d1369b9-86959e472243-a669baec95ff5981&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D7d132922-2D23b3ea8b-2D7d1369b9-2D86959e472243-2Da669baec95ff5981-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=bUkqIf98ir2n0fhlYgEu_c2k4w8oW1idwDGwyySsfhA&e=>
> w.
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>>>> utur
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
> 9
> >>>>>> c753a1d
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
> 2B
> >>>>>> RAlZTXBv5
> >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Teas mailing list
> >>>>>> [e-mail]<mailto:[e-mail]>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=19c50183-4765c22a-19c54118-86959e472243-be7fb3e456e3f9a6&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D19c50183-2D4765c22a-2D19c54118-2D86959e472243-2Dbe7fb3e456e3f9a6-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=VhW4TGe4z7ZeD8qijXBRD9ZkiGcGBi0YJ6buh0kXY6A&e=>
> w
> >>>>>> .i
> >>>>
> >>
> etf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__etf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=3zktgPf9FDsA3X9B-avff6-WYBQH1mx7Z-UUkgUayBc&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> u
> >>>>>>
> >>>>
> >>
> turewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__turewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=reHowyeT_UiuqtGsQwTotMvswWqVsTdUD1WFd1iyKRA&e=>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
> 01
> >>>>>>
> >>>>
> >>
> 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
> G
> >>>>>>
> >>>>
> >>
> Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
> 0
> >>>>>
> >>>>> _______________________________________________
> >>>>> Teas mailing list
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=d37b5edd-8ddb9d74-d37b1e46-86959e472243-a54dacfae536c914&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3Dd37b5edd-2D8ddb9d74-2Dd37b1e46-2D86959e472243-2Da54dacfae536c914-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=KontY0Ex6UJRo2EpGG4LrA-TsJBJxvvILb-PVW6PMdI&e=>
> w.
> >>>>>
> >>>>
> >>
> ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>> utur
> >>>>>
> >>>>
> >>
> ewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
> 9
> >>>> c753a1d
> >>>>>
> >>>>
> >>
> 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
> BL
> >>>> sLRq9T9a
> >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
> >>>>>
> >>
> >> _______________________________________________
> >> Teas mailing list
> >> [e-mail]<mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=H2IkukcySu5L351hyjuLvFIrQ8xp245DL4MTOrIYm3g&e=>


--
___________________________________________
Luis M. Contreras
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>
Global CTIO unit / Telefonica