Re: [Teas] Proposed text on "IETF Network Slicing Service"

[Krzysztof Szarkowicz <[e-mail]>]

Hi,

I have comment to Section 4.1.1

When we specify "Guaranteed Maximum Latency” or "Maximum Permissible Delay Variation” or "Maximum Permissible Packet Loss Rate”, we always need to specify “Maximum Bandwidth” for which these maximum latency/jitter/loss parameters apply. For example, if the customer requests:

Guaranteed Minimum Bandwidth = 1 Mbps
Guaranteed Maximum Latency = 1 ms

Now, the slice customer sends 1000 packets per second, each packet 1500 bytes (i.e. 1.5 Mbps). The slice provider delivers these packets, without any drop, but 10% of packets have delay > 5 ms. Is the SLO fulfilled? That could be questionable. 

MEF, for example, defines CIR (Committed Information Rate -> Guaranteed Minimum Bandwidth) and PIR (Peak Information Rate -> Maximum Bandwidth) for such scenario. Is the assumption with IETF Network slice that CIR and PIR are always equal? 

Let me add some comments inline as well.

Krzysztof

> On 2021 -Aug-23, at 12:00, Adrian Farrel <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Luis,
>  
> Responding on this thread during your vacation is beyond the call of duty!
>  
> Thanks John for your comments.
>  
> I am going to do post a revision of the document with some updated text to give us all a clear view of what the baseline text is. We can, of course, continue to refine that text.
>  
> There are some more answers (and promises for clarifying text that is now included in the version I am going to post) below.
>  
> Best,
> Adrian
>  
> >> 3.2. IETF Network Slice Service
> >>
> >> 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 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.  
> > 
> > [Luis>>] Does it mean that only the sending SLOs/SLEs would be
> > considered? For instance, in MP situations, a given CE in the
> > receiving direction could have limitations if all the sending parties
> > simultaneously use the peak capacity. Expressing such limitations
> > could help for instance to make the IETF NSC to infer the need of
> > applying some shaping to the traffic. Thus, it can be convenient
> > also to express the SLOs/SLEs in the receiving direction as well. 
> > (This applies also to the hub and spoke case referred below)
>  
> While knowledge of the receiver’s capabilities are important to determine the SLOs/SLEs at the sender, isn’t it normal for the CEs to be responsible for the policing and flow control at the ingress side: the network itself is not involved in policing or shaping beyond handling traffic that is in excess of any reservations. I think that is the standard model for transport (underlay, TE) protocols.
> [Luis>>] Clear the point for the CE. However (and, precisely, because the fact that the CE is not responsible for policing at the ingress side) we could expect that the network assumes the responsibility of handling the traffic delivered to the CE to be compliant with the expectations of the customer in terms of SLOs/SLEs also in the receiving direction. The only possibility of doing so is by providing such information at the time of requesting the slice. 
>  
> [JD]  Ingress policing does not prevent congestion on an egress CE.  Rather, what is needed is flow control between an egress CE and each of the ingress CEs that is sending to it.
>  
> [AF] It seems that there are two things here:
> Flow control between sender and receiver. I believe this is an overlay function and not the responsibility of the service. So I won’t include anything in this document.
> Receiver SLOs/SLEs. John and Luis seem to disagree about this function. While it seems to me to be possible, within the definitions of SLA and SLO/SLE, to attach them to a receiver, they seem really to apply to sender-receiver pairs. That is, the measure of network behaviour is applied to the traffic from sender to receiver. This is, of course, complicated in mp2p scenarios because in these cases the receiver may be stressed.
> What I am going to do here is proceed with the current text, but suggest that the discussion of applying SLOs/SLEs to receivers should remain open.
>  
[KS] For MP2MP or MP2P scenarios we certainly need receiver SLOs/SLEs - I fully agree here with Luis. Imagine a MP2MP slice, with 20 CEs, where the intent is all these 20 CEs can communicate to each other, and slice provider must ensure 1 Gbps upstream and 5 Gbps downstream for each of these CEs. How this can be specified without specifying receiver SLOs? Please note, this type of SLOs for MP2MP service is very common today for business VPNs, so it is really nothing new. 

> >> I.e., in a given IETF Network Slice Service
> >> there may be multiple 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.  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.
> > 
> > [Luis>>] I'm not sure about this. I think it is more clear to have a
> > single connectivity matrix per slice service. Let me explain why. In
> > my understanding, each connectivity matrix is elicited to satisfy a
> > given service with certain (and particular) SLOs/SLEs that make it
> > different from another service of the same customer. That is, the
> > customer wants to differentiate those services on purpose. And
> > at the time of requesting those services, the customer will ask for
> > different slices (as a service) to support them. In summary for me
> > it is more natural to associate one single matrix per slice. Also
> > note the complexity of handling those different matrices during
> > the lifecycle. We would require some form of identifier or 
> > distinguisher for each of them. Imagine that the customer wants
> > to modify some of the matrices but not all. How to refer to such
> > specific matrix? How to manage the different lifecycles of each
> > matrix? All becomes much more simpler if we manage a single
> > connectivity matrix per slice. And finally, how can be ensure the
> > consistency of requirements between matrices in terms of
> > SLOs/SLEs for a common CE? Inconsistencies can appear.
>  
> It is important that the architecture allow you to run your network the way you want. So it is a requirement that you should be permitted to specify each IETF network slice with exactly one connectivity matrix. 
>  
> I think that my proposed text allows exactly this as a specific case of the more general approach that also enables those who want to to define more than one connectivity matrix within a slice.
> [Luis>>] Probably I’m not understanding well the point. In my view, one slice should have only one connectivity matrix. This means that whatever SLOs/SLEs in the matrix are unique per CE pair (I comment on this as response to some of your clarifications later on). For example, between CE_1 and CE_2 the SLOs/SLEs = {SLx_1-2} are unique. If we require different SLOs/SLEs among the same two CEs that would be part of a different slice. Going on this way, the relation between slice and connectivity matrix is direct and unique.
> With the other commented approach of having multiple connectivity matrices associated to a single slice, that is, having two different sets of SLOs/SLEs between CE_1 and CE_2 (ex., SLOs/SLEs-A = {SLx_1-2-A} and SLOs/SLEs-B = {SLx_1-2-B}), the relationship between slice and connectivity matrix is not direct and would be necessary to use additional identifiers for discriminating each of the connectivity matrices of that slice to avoid any ambiguity.
> In summary, in my view, the proper way to follow, as you indicate, is “to specify each IETF network slice with exactly one connectivity matrix”. I would say “one and only one”, expressing in that matrix the relationship of all the CEs that intervene in the slice.
>  
> [JD]  As has been explained previously, there are requirements for intra-IETF network slice service connectivity that are richer than yours.  Further, your requirements are met with the model.
>  
> [AF] 
> (Please see the answer to the next comment for a dawning realization that we may be stumbling over the words “connectivity matrix”)
>  
> The points here are:
> It MUST be possible for Luis to run his network with one connectivity matrix per slice
> It SHOULD be possible for a slice to contain more than one connectivity matrix
> I think that gives us…
> A customer/provider relationship contains 0, 1, or more slice services
> A slice service contains 1 or more connectivity matrices
> A connectivity matrix contains 1 or more ingress CEs and 1 or more egress CE
> An ingress CE *in*a*matrix* is associated with a set of SLOs and SLEs
>  
> That is…
> A CE may be an ingress in 0, 1, or more connectivity matrices
> That CE is associated with a (different) set of SLOs and SLEs for each connectivity matrix where it is an ingress
>  
> My reading of the current text is that:
> It supports a slice having more than one connectivity matrix
> It does not require a slice to have more than one connectivity matrix
>  
> It is important to note that this framework does not dictate deployment models. That is, the ability to support >1 connectivity matrix in a slice does not require an operator to offer that facility to their customer.
>  
> The bottom line is that some operators may prefer to offer their customer a larger number of more granular slice services (each with a single connectivity matrix), while another operator may wish to offer their customer a “packaged” slice service (with the possibility of multiple matrices in a slice).
>  
> I have checked that the text will include:
> The service contains *one or more* connectivity matrices
> A CE may be a sending CE in one or more matrices in a slice
> A sending CE has a set of SLOs/SLEs for each matrix it belongs to
> Clarity that this is a deployment choice
> 


[KS] Also, I have another comment. The slice might have multiple traffic classes, each class with different SLOs/SLEs. For example, eMBB 5G slice might be used to deliver Internet + video streaming + mobile TV + real-time content, etc. All these traffic classes obviously might require different SLOs, e.g. in terms of latency or jitter. Is this concept of multiple connective matrices per single slice applicable to this use case? I.e., slice customer might request multiple connectivity matrices, between exactly the same set of CEs, and the only difference is SLO per each connectivity matrix (end points are the same)? 


> >> 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.
> > 
> > [Luis>>] I suppose that the SLOs/SLEs would be expressed by pairs,
> > i.e., CEx <-> CEy, right? So the set of SLOs/SLEs would be per pair of
> > CEs. Otherwise we would have a list (array) and not a matrix. (This
> > comment can also apply to the other cases with the corresponding
> > particularity for each of them)
>  
> When you define a point-to-multipoint connectivity construct (or multipoint-to-multipoint) the idea is that all traffic from any sender gets delivered to all receivers. That is, it is a connection, not a topology. Thus, the SLO/SLE set for a sender in a connectivity construct applies to all the receivers in that connectivity construct. I think this is clearly stated.
> [Luis>>] I think this could not apply for the case of slicing. The reason for that is because the traffic from one CE to other CEs could be very different in nature (that is on required SLOs/SLEs). For instance, let me take as example the radio functional split case documented in draft-contreras-teas-slice-nbi-05, section 4.5 / figure 5. There you can see the DU component dealing simultaneously with fronthaul and midhual traffic. This traffics show very different characteristics in terms of BW, jitter, etc. Thus we need to find the way of expressing the different connections that a single CE could require. This is why I think the SLOs/SLEs should be expressed by pairs, i.e., CEx <-> CEy, or at least, this form should be allowed. 
>  
> [JD]  Just define multiple P2P connectivity constructs between the various IETF network slice service CEs.  The model covers this.
>  
> [AF] I do believe that there is something here that is a major confusion of understanding!
>  
> There is a big difference between a topology and a virtual wire.
> Thus, with a topology that connects a set of CEs, you can send traffic between any pair of CEs.
> But with a virtual wire, you can only send where the wire goes.
>  
> In the case of a P2MP topology, the *one* sender can send to any of the receivers. They may send unicast or multicast flows.
> In the topology frame of thinking, an L3VPN is an MP2MP topology.
>  
> In the case of a P2MP connection (virtual wire), the sender sends to all receivers (the receivers may later decide to discard received packets, but that is a different matter).
> In the connectivity way of thinking, an L3VPN is a set of P2P connections.
>  
> I suspect that “matrix” may be causing confusion. For some people, “matrix” may imply the edges of a topology with a set of potential connectivities, while the document is intending to imply simply a connection. In this sense, “matrix” is being used consistently with “traffic matrix”, so I don’t think it is entirely the wrong term to use.
>  
> My resolution is to add a little text to clarify the term.
>  
[Krzysztof] And, we still need receiver SLOs for MP2MP (and MP2P, as a matter of fact).

> >> 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.
> >>
> >> If an IETF network slice service customer wants to have hub and spoke
> >> connectivity between N CEs in order to control how traffic is
> >> distributed between its CEs, it requests a set of N - 1 P2P
> >> unidirectional connectivity matrices, each between a sending CE spoke
> >> and the hub CE, and a P2MP connectivity matrix between the sending CE
> >> hub and the spoke CEs.
> > 
> > [Luis>>] Actually this can be represented by a single, common matrix, 
> > no need of considering {(N-1)+1} different matrices bounded in some
> > form.
>  
> I agree that the mp2mp construct defines (at the service level) the correct connectivity as seen by the CEs, it doesn’t represent the hub and spoke functionality.
>  
> An operator may decide to deliver mp2mp via a hub, but that is not the point.
>  
> If the *customer* wants to achieve hub and spoke functionality (presumably through their own hub site) then they can do as the text describes. 
>  
> Actually, I’m not very attached to the text here, but someone (can’t recall who – I could look it up) requested that we describe how to achieve this.
> [Luis>>] Again, probably I’m not understanding well the point, or I’m interpreting it in a different manner. What I’m referring to is to express the connectivity like this (in the example, applied to hub and spoke, but valid for any kind of connectivity)
>      +-----+-----+-----+-----+
>      | CEh | CE1 | CE2 | CE3 |
> -----+-----+-----+-----+-----+
> |CEh |     |sloh1|sloh2|sloh3|
> -----+-----+-----+-----+-----+
> |CE1 |slo1h|     |     |     |
> -----+-----+-----+-----+-----+
> |CE2 |slo2h|     |     |     |
> -----+-----+-----+-----+-----+
> |CE3 |slo3h|     |     |     |
> -----+-----+-----+-----+-----+ 
> That is, one single matrix serves to express the connectivity among all the CEs participating in the slice. 
>  
> [JD]  The statement was referring to a hub an spoke construct between the IETF network slice service CES, i.e., it is external to the IETF network slices service provider.  Therefore, it needs to be expressed in terms of connectivity constructs understood by the IETF network slice service provider.
>  
> [AF] It is, of course, true that an operator may deliver mp2mp connectivity within their network using hub-and-spoke. That is entirely their business, and the customer has no visibility into this. (I suppose we could make an SLE as “Deliver this connectivity using hub-and-spoke”, but no one is asking for that so far.) What is important to note here is that the connectivity matrix describes what the customer sees in terms of “send from here, receive over there” and not how the operator achieves that connectivity.
>  
> However, this paragraph cover the case where the customer wants to build their own hub-and-spoke service. Please don’t ask me why – I only know that: i. it is technically possible; ii. there was a request to describe it.
> In this case, the customer designates a CE as “hub” and then creates a set of p2p connectivity matrices between CEs and the hub, relying on the hub to replicate and forward the packets.
>  
> >> It should be noted that per Section 9 of [RFC4364] an IETF network
> >> slice service customer may actually provide IETF network slice
> >> services to other customers.  In this case, the underlying IETF
> >> network slice service provider may be owned and operated by the same
> >> or a different provider network.
> > 
> > [Luis>>] It is not clear to me the sense of the last sentence. Is the
> > purpose of the sentence the following? -> In this case, the underlying
> > IETF network slice service provider may be owned and operated by
> > A SINGLE OR MULTIPLE providers' networks.
>  
> No. This is the “carrier’s carrier” model where the a provider (Provider A) may offer slice services to a customer that is, itself a provider (Provider B). Provider B may also offer slice services to other customers. Provider B may be an internal customer of Provider A (i.e., a sub-division) or an external customer (carrier’s carrier).
>  
> This text could probably be clearer. I’ll work on it.
> [Luis>>] Ok
> 
> >> Section 4.2 provides a description of endpoints in the context of
> >> IETF network slicing.  For a given IETF network slice service, the
> >> IETF network slice customer and provider agree, on a per-CE basis
> >> which end of the attachment circuit provides the service demarcation
> >> point.  This determines whether the attachment circuit is included in
> >> the set of SLOs and SLEs for the subject CE.
> > 
> > [Luis>>] For the last sentence, would it not be more precise to
> > comment in this way? -> This determines whether the attachment
> > circuit is included as part of the IETF network slice service (then
> > being also the object of the set of SLOs and SLEs for the subject CE).
>  
> Yeah, sort of. I mean, whether the AC is part of the service does determine whether or not the AC is part of the service 😊
>  
> Perhaps…. 
>  
>   For a given IETF network slice service, the
>    IETF network slice customer and provider agree, on a per-CE basis
>    which end of the attachment circuit provides the service demarcation
>    point (i.e., whether the attachment circuit is inside or outside the 
>    IETF network slice service).  This determines whether the attachment
>    circuit is subject to the set of SLOs and SLEs for the specific CE.
> [Luis>>] perfectly fine, thanks
>  
> Cheers,
> Adrian
>  
> From: Luis M. Contreras <[e-mail] <mailto:[e-mail]>> 
> Sent: 12 August 2021 11:53
> To: [e-mail] <mailto:[e-mail]>
> Cc: TEAS WG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Teas] Proposed text on "IETF Network Slicing Service"
>  
> Hi Adrian,
>  
> some questions from my side on the proposed text, in-line.
>  
> Thanks in advance, best regards
>  
> Luis
>  
>> 
>> 
>> ===
>> 
>> 3.2. IETF Network Slice Service
>> 
>>    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 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.  
>  
> [Luis>>] Does it mean that only the sending SLOs/SLEs would be considered? For instance, in MP situations, a given CE in the receiving direction could have limitations if all the sending parties simultaneously use the peak capacity. Expressing such limitations could help for instance to make the IETF NSC to infer the need of applying some shaping to the traffic. Thus, it can be convenient also to express the SLOs/SLEs in the receiving direction as well. (This applies also to the hub and spoke case referred below)
>  
>> I.e., in a given IETF Network Slice Service
>>    there may be multiple 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.  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.
>  
> [Luis>>] I'm not sure about this. I think it is more clear to have a single connectivity matrix per slice service. Let me explain why. In my understanding, each connectivity matrix is elicited to satisfy a given service with certain (and particular) SLOs/SLEs that make it different from another service of the same customer. That is, the customer wants to differentiate those services on purpose. And at the time of requesting those services, the customer will ask for different slices (as a service) to support them. In summary for me it is more natural to associate one single matrix per slice. Also note the complexity of handling those different matrices during the lifecycle. We would require some form of identifier or distinguisher for each of them. Imagine that the customer wants to modify some of the matrices but not all. How to refer to such specific matrix? How to manage the different lifecycles of each matrix? All becomes much more simpler if we manage a single connectivity matrix per slice. And finally, how can be ensure the consistency of requirements between matrices in terms of SLOs/SLEs for a common CE? Inconsistencies can appear.
>  
>> 
>>    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.
>  
> [Luis>>] I suppose that the SLOs/SLEs would be expressed by pairs, i.e., CEx <-> CEy, right? So the set of SLOs/SLEs would be per pair of CEs. Otherwise we would have a list (array) and not a matrix. (This comment can also apply to the other cases with the corresponding particularity for each of them)
>  
>> 
>>    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.
>> 
>>    If an IETF network slice service customer wants to have hub and spoke
>>    connectivity between N CEs in order to control how traffic is
>>    distributed between its CEs, it requests a set of N - 1 P2P
>>    unidirectional connectivity matrices, each between a sending CE spoke
>>    and the hub CE, and a P2MP connectivity matrix between the sending CE
>>    hub and the spoke CEs.
>  
> [Luis>>] Actually this can be represented by a single, common matrix, no need of considering {(N-1)+1} different matrices bounded in some form.
>  
>> 
>>    It should be noted that per Section 9 of [RFC4364] an IETF network
>>    slice service customer may actually provide IETF network slice
>>    services to other customers.  In this case, the underlying IETF
>>    network slice service provider may be owned and operated by the same
>>    or a different provider network.
>  
> [Luis>>] It is not clear to me the sense of the last sentence. Is the purpose of the sentence the following? -> In this case, the underlying IETF network slice service provider may be owned and operated by A SINGLE OR MULTIPLE providers' networks.
>  
>> 
>>    Section 4.2 provides a description of endpoints in the context of
>>    IETF network slicing.  For a given IETF network slice service, the
>>    IETF network slice customer and provider agree, on a per-CE basis
>>    which end of the attachment circuit provides the service demarcation
>>    point.  This determines whether the attachment circuit is included in
>>    the set of SLOs and SLEs for the subject CE.
>  
> [Luis>>] For the last sentence, would it not be more precise to comment in this way? -> This determines whether the attachment circuit is included as part of the IETF network slice service (then being also the object of the set of SLOs and SLEs for the subject CE).
>  
>> 
>> _______________________________________________
>> Teas mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TsmZWoyJXtYD4g19RwcGRX20UYh4KicVm7XzSbZujHIIocQOMvVtKV9OhhjL_O0$>
> 
>  
> -- 
> ___________________________________________
> Luis M. Contreras
> [e-mail] <mailto:[e-mail]> 
> [e-mail] <mailto:[e-mail]>
> Global CTIO unit / Telefonica
>  
> 
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>