Subject: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 7 Oct 2021 11:03:26 +0000

Hi Adrian,

Apologies for my late response on this.

In my opinion, I think that the following aspects should be elaborated more:

.- receiving SLOs/SLEs, as discussed in the specific thread on the topic.
.- operation of multiple connectivity matrices: if some SLO is modified at a CE during slice lifetime, in case of having multiple matrices, the impacted matrix should be identified somehow. Same things happen, for instance, when adding new endpoints to an existing slice (we need to identify somehow the affected matrices for this addition).
.- “Traffic sent by any sender in the matrix is delivered to all receivers (except back to itself).” -> It should be clear if this is performed in a multicast-like manner or not, since the SLOs derived from that for some parameters (e.g., throughput) can be cumulative.

Thanks,

Best regards

Luis

De: Adrian Farrel <[email-masked]>
Enviado el: miércoles, 29 de septiembre de 2021 13:11
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: 'TEAS WG' <[email-masked]>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi Luis,

Replying on this thread branch, but equally applicable to the exchange you're having with Igor.

Yes, our aim should be to get wording that is clear and captures our intent.

I deliberately started my cluster of issues with "Issue #1: What is a connectivity matrix?" because getting that definition clear (and right!) is fundamental to a lot of the other discussion. I think you and Igor are proving that this is correct - we have to tighten our definitions here.

In that thread I wrote

> Note that a p2mp connectivity matrix means that traffic placed on the matrix

> will be delivered to all the destination endpoints.

And then I asked

> Does the text in the draft need more clarity on this point?

Perhaps we should go back to what -04 currently says in Section 3.2

   A service provider instantiates an IETF network slice service for a

   customer.  The IETF network slice service is specified in terms of a

   set of the customer's endpoints (CEs), a set of one or more

   connectivity matrices (point-to-point (P2P), point-to-multipoint

   (P2MP), multipoint-to-point (MP2P), or multipoint- to-multipoint

   (MP2MP)) between subsets of these CEs, and a set of SLOs and SLEs for

   each CE sending to each connectivity matrix.  That is, in a given

   IETF Network Slice Service there may be one or more connectivity

   matrices of the same or different type, each connectivity matrix may

   be between a different subset of CEs, and for a given connectivity

   matrix each sending CE has its own set of SLOs and SLEs, and the SLOs

   and SLEs in each set may be different.  However, it is a free choice

   for a service provider to decide whether to implement a single

   connectivity matrix per IETF Network Slice Service, or to allow

   multiple matrices per slice.

   Note that in this context a "connectivity matrix" is a connection

   between a set of senders and a set of receivers.  Traffic sent by any

   sender in the matrix is delivered to all receivers (except back to

   itself).  Thus, a connectivity matrix may be treated in the manner of

   a virtual wire.

   It is also the case that a given sending CE may be part of multiple

   connectivity matrices within a single IETF network slice service, and

   the CE may have different SLOs and SLEs for each connectivity matrix

   to which it is sending.  Note that a given sending CE's SLOs and SLEs

   for a given connectivity matrix apply between it and each of the

   receiving CEs for that connectivity matrix.

   This approach results in the following possible connectivity

   matrices:

   o  For an MP2MP connectivity matrix with N CEs, each of the N sending

      CEs has its own set of SLOs and SLEs and they may all be

      different.

   o  For a P2MP connectivity matrix, there is only one sending CE, and

      there is only one set of SLOs and SLEs.

   o  For an MP2P connectivity matrix with N CEs, there is one receiving

      CE and (N - 1) sending CEs.  Each sending CE has its own set of

      SLOs and SLEs and they may all be different.

   o  For a P2P unidirectional connectivity matrix, there is only one

      sending CE and there is only one set of SLOs and SLEs.

   o  For a P2P bidirectional connectivity matrix, there are two sending

      CEs, there are two sets of SLOs and SLEs which may be different.

It would be excellent if you and Igor could indicate, in the light of what we have learnt in the current discussion, what changes to this text would be appropriate.

Thanks,

Adrian

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
Sent: 29 September 2021 08:51
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi John,

Then it should be clearly stated in the draft that p2mp implies multicast-like delivery (i.e., replication, not addition of the different contributions to the receiving parties).

Best regards

Luis

-----Mensaje original-----

De: John E Drake <[email-masked]<mailto:[email-masked]>>

Enviado el: martes, 28 de septiembre de 2021 20:09

Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>

CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----

> From: LUIS MIGUEL CONTRERAS MURILLO

> <[email-masked]<mailto:[email-masked]>>

> Sent: Tuesday, September 28, 2021 12:23 PM

> To: John E Drake <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct

> <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> per receiver

> [External Email. Be cautious of content]

> Hi John,

> 8< --

> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a

> PT2MP connectivity matrix with a single sender, A, and single SLO, X,

> for it.  This is completely different than the case of three PT2PT

> connectivity matrices, A->B,

> A->C, and A->D.

> 8< --

> A p2mp connectivity matrix represents a hub and spoke architecture

> that do not necessarily implies the same content (a replica) should be

> received by all the spoke endpoints. At least this was my

> understanding. Thus you can have the same SLO (i.e., X) for all the

> endpoints or different ones (let's say X_b, X_c, etc) per endpoint.

> If a p2mp matrix implies a multicast-like delivery then whatever which

> is not a multicast slice should be expressed as a collection of p2p matrices.

[JD]  Either N**2  P2P or N MP2P.

> Best regards

> Luis

> -----Mensaje original-----

> De: John E Drake <[email-masked]<mailto:[email-masked]>>

> Enviado el: martes, 28 de septiembre de 2021 17:31

> Para: LUIS MIGUEL CONTRERAS MURILLO

> <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct

> <[email-masked]<mailto:[email-masked]>>

> CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per

> receiver

> Hi,

> Comments inline

> Yours Irrespectively,

> John

> Juniper Business Use Only

> > -----Original Message-----

> > From: LUIS MIGUEL CONTRERAS MURILLO

> > <[email-masked]<mailto:[email-masked]>>

> > Sent: Tuesday, September 28, 2021 11:02 AM

> > To: John E Drake <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct

> > <[email-masked]<mailto:[email-masked]>>

> > Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> > Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > per receiver

> > [External Email. Be cautious of content]

> > Hi John,

> > 8< --

> > [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D},

> > A has an SLO with a bandwidth X, which means that A sends X to the

> > network and the network delivers X to {B, C, D}.

> > 8< --

> > Do you mean that the network can deliver *up to* X for each of the

> > three B, C, D, but summing up a total of X among the three? Or do

> > you mean that the network replicates the X traffic generated by A to

> > deliver X to B, to C and to D

> > (=3X) in a sort of multicast?

> [JD]  The latter

> > If you refer to the first case, in case whatever of the other

> > endpoints, e.g. B, can only support a fraction of X, we are in the

> > same situation as I commented before. If you refer to the multicast

> > case, that statement can be valid, but does not represent what I

> > commented

> before.

> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a

> PT2MP connectivity matrix with a single sender, A, and single SLO, X,

> for it.  This is completely different than the case of three PT2PT

> connectivity matrices, A->B,

> A->C, and A->D.

> > Best regards

> > Luis

> > -----Mensaje original-----

> > De: John E Drake <[email-masked]<mailto:[email-masked]>> Enviado el: martes, 28 de

> > septiembre de 2021 16:10

> > Para: LUIS MIGUEL CONTRERAS MURILLO

> > <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct

> > <[email-masked]<mailto:[email-masked]>>

> > CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> > Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > per receiver

> > Hi,

> > Comment inline below.

> > As Joel correctly pointed out in one of his emails, the bandwidth of

> > the attachment circuit between a CE and a PE serves as the rate

> > limiter for traffic between that CE and PE, and that is completely

> > independent of the connectivity matrices, although specifying a

> > bandwidth greater than the attachment circuit bandwidth isn't

> > particularly

> useful.

> > Yours Irrespectively,

> > John

> > Juniper Business Use Only

> > > -----Original Message-----

> > > From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of LUIS MIGUEL

> > > CONTRERAS MURILLO

> > > Sent: Tuesday, September 28, 2021 9:35 AM

> > > To: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>

> > > Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> > > Subject: Re: [Teas] Network slicing framework : Issue #3:

> > > SLOs/SLEs per receiver

> > > [External Email. Be cautious of content]

> > > Hi Joel,

> > > Regarding the bandwidth example. If it was necessary to express

> > > the connectivity one by one (e.g., A -> B, A -> C, A -> D) instead

> > > of aggregated (i.e., A -> {B,C,D}) is precisely because of the

> > > receiver constraints, even they don't become expressed. Going in

> > > the aggregate form is simpler in my personal opinion. And for

> > > that, adding the receiver SLO

> > facilitates the simplification.

> > > Let me list the options for connectivity matrix in this example

> > > according to my understanding of the discussion:

> > > 1/ starting point in the draft today -- Connectivity matrix

> > > expressed in the form A

> > > (SLO_s=3*CAP) -> {B,C,D}, specifying only A SLO (in case of

> > > bandwidth example, it would be 3*CAP)

> > 2/ per-connection view (in order to accommodate

> > > sender+receiver constraints) -- Connectivity matrix expressed in

> > > sender+the form A

> > > (SLO_s=CAP) -> B, then A (SLO_s=CAP) -> C, then A (SLO_s=CAP) -> D.

> > > 3/ aggregated view (specifying SLOs per endpoint) -- A

> > > (SLO_s=3*CAP)

> > > -> {B(SLO_r=CAP), C(SLO_r=CAP), D(SLO_r=CAP)}

> > [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D},

> > A has an SLO with a bandwidth X, which means that A sends X to the

> > network

> and the network

> > delivers X to {B, C, D}.   If

> > you had three connectivity matrices A->B, A->C, and A->D, and A has

> > an SLO with a bandwidth X for each of them, then A sends 3X to the

> > network and the network delivers X to B, C, and D.

> > > While 1 does not provide enough information (can motivate

> > > overprovisioning), 2 requires of further processing to link all

> > > the three per-connection matrices together for the slice

> > > realization (note that the same kind of service is considered for

> > > all the three connections). In my view 3 is a more efficient and

> > > comprehensive way of

> > expressing the slice service need in this example.

> > > By the way, being 3 richer in terms of information, I think that

> > > moving from 3 to

> > > 2 for those that could prefer that connectivity matrix model is

> > > always

> possible.

> > > But not the other way around.

> > > Best regards

> > > Luis

> > > -----Mensaje original-----

> > > De: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> Enviado el:

> > > martes, 28 de septiembre de 2021 12:51

> > > Para: LUIS MIGUEL CONTRERAS MURILLO

> > > <[email-masked]<mailto:[email-masked]>>

> > > CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> > > Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > > per receiver

> > > I presume I am misreading your description below.

> > > If the constraint is that A can send no more than "CAP" to A, CAP

> > > to B, and CAP to C, but is not worried about the total being sent,

> > > then the SLO needs to say that separately as explicit sender constraints.

> > > We need to make sure that the the connectivity matrix can express

> > > that (I think it can).  Trying to express that as receiver

> > > constraints is misleading.  It is not that A can send 3*CAP to B,

> > > but B will only receive CAP.  It

> > is that A is constrained in what they send.

> > > Yours,

> > > Joel

> > > On 9/28/2021 5:02 AM, LUIS MIGUEL CONTRERAS MURILLO wrote:

> > > > Hi all,

> > > > Expressing the SLOs for both transmitters and receivers is

> > > > necessary for a proper mapping and realization of slice requests

> > > > by the IETF NSC. Let me give an example referring to two basic

> > > > SLOs, bandwidth and

> > > latency.

> > > > Let’s consider a p2mp communication A -> {B, C, D} where each

> > > > destination will receive from source A a flow of equal capacity Cap.

> > > > -Bandwidth: If we only specify the SLO of the sender, which is

> > > > 3*Cap, when mapping and realizing the slice for B, C and D, this

> > > > way of proceeding would imply that a capacity of 3*Cap should be

> > > > allocated for all of them (B, C and D). This clearly is a

> > > > wastage of

> resources.

> > > > It can be argued that an alternative way of expressing the need

> > > > is to create 3 different matrices A -> B, A ->C and A ->D each

> > > > of them specifying simply Cap. I think this is not the best way

> > > > of expressing the connectivity matrix of a slice, since it

> > > > implies further processing (i.e., the aggregation of needs on A

> > > > for realizing that the total need is 3*Cap) and because it loses

> > > > the nature of the service (p2mp), apart of probably requiring

> > > > some extra information to handle the association of those “individual”

> > > > matrices as part of an overarching connectivity matrix in the

> > > > slice. It is much more simpler to add the receiver SLO for later

> > > > mapping and

> realization.

> > > > -Latency: by expressing the different latency requirements in B,

> > > > C or D, it can be possible to assist on the realization of the

> > > > slice, for instance by selecting “Technology Y” instead of “Technology X”

> > > > to guarantee the delay limits of the receiver. Such a latency at

> > > > B, C or D essentially could reflect the fact that part of the

> > > > overall latency budget is spent on that endpoints for a given

> > > > service, so it can assist on the decisions of the IETF NSC for

> > > > determining the best slice realization solution to be within the

> > > > limits of the overall latency budget and ensure proper service delivery.

> > > > Best regards

> > > > Luis

> > > > *De:*Greg Mirsky <[email-masked]<mailto:[email-masked]>> *Enviado el:* martes,

> > > > 28 de septiembre de 2021 0:02

> > > > *Para:* Joel M. Halpern <[email-masked]<mailto:[email-masked]>>

> > > > *CC:* LUIS MIGUEL CONTRERAS MURILLO

> > > > <[email-masked]<mailto:[email-masked]>>;

> > > > [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

> > > > *Asunto:* Re: [Teas] Network slicing framework : Issue #3:

> > > > SLOs/SLEs per receiver

> > > > Hi Joel,

> > > > I agree with you that IPDV SLO at the egress seems only useful

> > > > as the threshold value, not as a target that the egress may enforce.

> > > > Further extending the distributed model, in some realization of

> > > > a network slice, SLOs can be used at the egress edge to monitor

> > > > the conformance of the network slice.

> > > > Regards,

> > > > Greg

> > > > On Mon, Sep 27, 2021 at 2:38 PM Joel M. Halpern

> > > > <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:

> > > >     It seems true that aggregating the sender SLOs inter-packet spacing

> > > >     will

> > > >     not tell you what inter-packet spacing the receiver can expect /

> > > >     require

> > > >     / ...

> > > >     But so what?  Unless we are talking about egress traffic shapers, the

> > > >     network is not going to enforce receiver-visible effects.  And so far,

> > > >     we have not included traffic shapers of any kind in our analysis

> > > >     (because they tend to be a mess, significantly worse than policers.

> > > >     If Luis' request for receiver based SLOs was intended to bring egress

> > > >     shapers into the IETF network slice, I think it is a bad idea.  And if

> > > >     it is not intended to do that, I do not know what it is intended to do.

> > > >     Yours,

> > > >     Joel

> > > >     On 9/27/2021 5:20 PM, Greg Mirsky wrote:

> > > >      > Hi John,

> > > >      > I suspect that not all SLOs at the receiving CE of the particular

> > > >      > network slice can be presented as the sum of the corresponding SLOs

> > > >      > defined for all senders to that CE. For example, BW SLO can be

> > > >      > summarized. But I don't see that interpacket delay variation can be

> > > >      > summarized to be useful for the receiver at the NSE.

> > > >      > Regards,

> > > >      > Greg

> > > >      > On Mon, Sep 27, 2021 at 11:00 AM John E Drake

> > > >      > <jdrake=[email-masked]

> > > >     <mailto:[email-masked]>

> > > >      > <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>> wrote:

> > > >      >     Adrian,

> > > >      >     The current definition is that the for a given sending

> > > >      >     CE/connectivity matrix the set of SLOs and SLEs apply to all

> > > >      >     receiving CEs for that connectivity matrix.  Sending CEs are

> > > >      >     independent, so for a given receiving CE for that connectivity

> > > >      >     matrix the set of SLOs and SLEs is effectively the sum of the

> > > >     set of

> > > >      >     SLOs and SLEs for each sending CE

> > > >      >     Yours Irrespectively,

> > > >      >     John

> > > >      >     Juniper Business Use Only

> > > >      >      > -----Original Message-----

> > > >      >      > From: Teas <[email-masked]

> > > >     <mailto:[email-masked]> <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>>

> > > >      >     On Behalf Of Adrian Farrel

> > > >      >      > Sent: Monday, September 27, 2021 12:37 PM

> > > >      >      > To: 'LUIS MIGUEL CONTRERAS MURILLO'

> > > >      >      > <[email-masked]

> > > >     <mailto:[email-masked]>

> > > >      >     <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>>; 'TEAS WG'

> > > >      >     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>> <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>>

> > > >      >      > Subject: [Teas] Network slicing framework : Issue #3:

> > > >     SLOs/SLEs

> > > >      >     per receiver

> > > >      >      > [External Email. Be cautious of content]

> > > >      >      > Hi,

> > > >      >      > Currently we say that SLOs/SLEs are specified for each

> > > >     sender on each

> > > >      >      > connectivity matrix. Thus, if we have A-B, A-C and A-{B,

> > > >     C, D} we

> > > >      >     would

> > > >      >      > configure 3 sets of SLOs/SLEs describing the required

> > > >     behaviour and

> > > >      >      > performance of the three connectivity matrices in terms of the

> > > >      >     traffic presented

> > > >      >      > at A.

> > > >      >      > Luis asks that we also consider configuring SLOs/SLE for the

> > > >      >     receivers on those

> > > >      >      > connectivity matrices.

> > > >      >      > I would like Luis to comment more on this requirement as

> > > >     (form my

> > > >      >      > perspective) the SLOs/SLEs describe how traffic should be

> > > >      >     serviced by the

> > > >      >      > network, not the performance of the receiver. But the expected

> > > >      >     traffic arriving

> > > >      >      > at the receiver can be deduce from the traffic at the senders.

> > > >      >      > If, on the other hand, the receiver knows that it must receive

> > > >      >     traffic with no

> > > >      >      > more than a certain jitter, this is (presumably) a feature

> > > >     of the

> > > >      >      > application/service being run over the slice so it is equally

> > > >      >     configurable at the

> > > >      >      > sender.

> > > >      >      > Thanks,

> > > >      >      > Adrian

> > > >      >      > _______________________________________________

> > > >      >      > Teas mailing list

> > > >      >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> > > te

> > > as

> > > __;!!N

> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> > > te

> > > as

> > > __;!!N

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!

> > > N

> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> > > te

> > > as

> > > __;!!N

> > > >      >      > Et6yMaO-gk!WHlUOHwVHgCbTvsslIOUbtuzc_c53VJCxP2Q25d3y-

> > > >      >      > JnoPmU4ovtQ6bRJWriFrE$

> > > >      >     _______________________________________________

> > > >      >     Teas mailing list

> > > >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]

> > > >     <mailto:[email-masked]>>

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> > > te

> > > as

> > > __;!!N

> > > Et6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!

> > > NEt6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $ >

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!

> > > NEt6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!

> > > NEt6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $ >>

> > > >      > _______________________________________________

> > > >      > Teas mailing list

> > > >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> > > te

> > > as

> > > __;!!N

> > > Et6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!

> > > NEt6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $ >

> > > > ----------------------------------------------------------------

> > > > --

> > > > --

> > > > --

> > > > --

> > > > 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

> > > ________________________________

> > > 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

> > > [email-masked]<mailto:[email-masked]>

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> > > te

> > > as

> > > __;!!N

> > > Et6yMaO-

> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4

> > > $

> > ________________________________

> > 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

> ________________________________

> 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

________________________________

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

________________________________

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