Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt

From: "Wubo (lana)" <[email-masked]>
Date: Mon, 8 Nov 2021 11:23:30 +0000

Hi Tarek,

Apologies for chiming in.  I also have some questions on slice aggregate, please see inline.

Thanks,
Bo

发件人: Teas [mailto:[email-masked]] 代表 Tarek Saad
发送时间: 2021年11月8日 12:12
收件人: Dongjie (Jimmy) <[email-masked]>; Tarek Saad <tsaad=[email-masked]>; [email-masked]
抄送: [email-masked]
主题: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi Jie,

See below.

>> In previous versions, it was described as the underlay network construct which the IETF network slice service are mapped to. With the introduction of the generic term “Network Resource Partition”, it seems now slice aggregate is only used to refers to “a collection of packets”, and “comprises of one or more IETF network slice traffic streams”.
[TS]: the “Network Resource Partition” is used to describe the set of resources that are instantiated of specific link/nodes in the network to support the slice aggregate. The slice aggregate definition has not changed and identifies the collection of slice streams/flows (that can share common SLOs and aggregated together) and that traverse the Network Resource Partition. The two terms are distinct, and describe different things and I don’t think removing one will help in any way.

>> Do you see anything missing if we simply use “slice traffic” or “slice traffic flows”?
[TS]: slice aggregate designates a special relation between the select slice traffic flows (as per the definition set in the draft). As you see, we have chosen to refer to the set of select ‘slice traffic flows’ as slice aggregate to distinguish it from any general collection of slice traffic flows.

[Bo]: I don’t quite get the explanation. I understand NSC needs to map NS service to NRP, and I think this mapping is quite similar to draft-ietf-teas-te-service-mapping, which defines the mapping between service YANG and underlying TE resources.  There is no VPN service aggregate concept in it, and how VPN service traffic are mapped to TE resources is an internal process of a network controller. Why would we define slice aggregate, are the slice aggregate traffic flows different with NS service traffic flows? NS service model defines “ns-match-criteria”, what is the relationship between slice aggregate and this criteria?

Regards,
Tarek

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 5, 2021 at 11:43 AM
To: Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt
Hi Tarek,

Thanks for the update.

I am glad to see this version is much improved. However, it is not quite clear to me whether the term "slice aggregate" is still needed or not.

In previous versions, it was described as the underlay network construct which the IETF network slice service are mapped to. With the introduction of the generic term “Network Resource Partition”, it seems now slice aggregate is only used to refers to “a collection of packets”, and “comprises of one or more IETF network slice traffic streams”.

To my understanding, this is no more than a collection of packets which will be mapped to a particular network resource partition. In that case, we could simply call it “slice traffic” or “slice traffic flows”.

Both traffic and flow are generic and could express the notion of aggregate. For example, as described in RFC7011,

"A Flow is defined as a set of packets or frames passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties."

Do you see anything missing if we simply use “slice traffic” or “slice traffic flows”?

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Tarek Saad
Sent: Monday, October 25, 2021 10:28 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi WG,

This update includes the following:
・        Several nit edits
・        Use of the generic term “Network Resource Partition” to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
・        New section 3 for “IETF Network Slice Realization”
Regards,
Tarek (for co-authors)

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 25, 2021 at 9:53 AM
To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>, EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>, Joel Halpern <[email-masked]<mailto:[email-masked]>>, Luis Contreras <[email-masked]<mailto:[email-masked]>>, Ran Chen <[email-masked]<mailto:[email-masked]>>, Reza Rokui <[email-masked]<mailto:[email-masked]>>, Shaofu Peng <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

A new version of I-D, draft-bestbar-teas-ns-packet-04.txt
has been successfully submitted by Tarek Saad and posted to the
IETF repository.

Name:           draft-bestbar-teas-ns-packet
Revision:       04
Title:          Realizing Network Slices in IP/MPLS Networks
Document date:  2021-10-22
Group:          Individual Submission
Pages:          32
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$>
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$>
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$>
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$>

Abstract:
   Network slicing provides the ability to partition a physical network
   into multiple logical networks of varying sizes, structures, and
   functions so that each slice can be dedicated to specific services or
   customers.  Network slices need to operate in parallel while
   providing slice elasticity in terms of network resource allocation.
   The Differentiated Service (Diffserv) model allows for carrying
   multiple services on top of a single physical network by relying on
   compliant nodes to apply specific forwarding treatment (scheduling
   and drop policy) on to packets that carry the respective Diffserv
   code point.  This document adopts the Diffserv principles and
   proposes a scalable approach to realize network slicing in IP/MPLS
   networks.  The solution does not mandate Diffserv to be enabled in
   the network to provide a specific forwarding treatment, but can co-
   exist with and complement it when enabled.

The IETF Secretariat

Juniper Business Use Only

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Nov 2021 12:51:16 +0000

Hi Bo,

See inline [TSTS]..

From: Wubo (lana) <[email-masked]>
Date: Monday, November 8, 2021 at 6:23 AM
To: Tarek Saad <[email-masked]>, Dongjie (Jimmy) <[email-masked]>, Tarek Saad <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

Hi Tarek,

Thanks,
Bo

Hi Jie,

See below.

[Bo]: I don’t quite get the explanation. I understand NSC needs to map NS service to NRP, and I think this mapping is quite similar to draft-ietf-teas-te-service-mapping, which defines the mapping between service YANG and underlying TE resources.  There is no VPN service aggregate concept in it, and how VPN service traffic are mapped to TE resources is an internal process of a network controller. Why would we define slice aggregate, are the slice aggregate traffic flows different with NS service traffic flows? NS service model defines “ns-match-criteria”, what is the relationship between slice aggregate and this criteria?
[TSTS]: Indeed, the two are different - let me clarify. The ‘ns-match-criteria’ defined in the NS NBI YANG model is relevant on the ingress to identify/match incoming traffic that belongs a single IETF network slice service – this, for example, can be a VLAN tag on the CE-PE link.
Within the transport network, and to allow for scale, nodes part of the ‘Network Resource Partition’ will apply forwarding treatment (e.g. queuing and QoS policies) based on an aggregation of such IETF NS service traffic streams (as opposed to applying forwarding treatment on per traffic flow treatment which is understood not to scale).

Regards,
Tarek

Thanks for the update.

Best regards,
Jie

Hi WG,

  *   Several nit edits
  *   Use of the generic term “Network Resource Partition” to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
  *   New section 3 for “IETF Network Slice Realization”
Regards,
Tarek (for co-authors)

Abstract:

The IETF Secretariat

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 8 Nov 2021 16:39:59 +0000

Hi Tarek,

Please see further inline with [Jie #2]:

From: Tarek Saad [mailto:[email-masked]]
Sent: Monday, November 8, 2021 8:51 PM
To: Wubo (lana) <[email-masked]>; Tarek Saad <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi Bo,

See inline [TSTS]..

From: Wubo (lana) <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 8, 2021 at 6:23 AM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

Hi Tarek,

Thanks,
Bo

发件人: Teas [mailto:[email-masked]] 代表 Tarek Saad
发送时间: 2021年11月8日 12:12
收件人: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi Jie,

See below.

[Jie #2] Please see my previous reply to Pavan. Although the text about the slice aggregate definition has no change, several of its usage in the draft have been replaced by network resource partition directly in this version, while some others were not. This may cause some confusions. Thus the relationship between slice aggregate and network resource partition needs further clarification.

Confirming that a slice aggregate is a collection of slice streams/flows with shared common SLO is a good starting point to distinguish it from the underlay network construct which is now called network resource partition.  Then another question is: do you consider there is always 1:1 mapping between the slice aggregate and the resource partition?

[Jie #2] The traffic flows are grouped by different network slices. According to the previous discussion on the multiple connectivity matrix and SLOs in a slice, it is assumed that the flows in the same slice may have different SLOs. Following this, the flows which belong to one slice aggregate may come from different slices. Then more precisely it should be called “slice traffic/flow aggregate”. This was also raised before during mail list discussion.

[Jie #2] Following Bo’s comment, as the ns-matching-criteria is for the matching of an individual network slice service, should there also be the matching criteria for slice aggregate in the NS Service YANG model?  Or what would be the mechanism to match slice traffic flows into a slice aggregate in the controller?

The mechanism you described about the forwarding treatment on the packet is performed by network nodes involved in a network resource partition based on the identifier of the resource partition in the packet, which is after the traffic flows are mapped to the resource partition. I hope this is not mixed up with the procedure of mapping the network slice flows to the slice aggregate.

Best regards,
Jie

Regards,
Tarek

Thanks for the update.

Best regards,
Jie

Hi WG,

This update includes the following:
·       Several nit edits
·       Use of the generic term “Network Resource Partition” to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
·       New section 3 for “IETF Network Slice Realization”
Regards,
Tarek (for co-authors)

Abstract:

The IETF Secretariat

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Nov 2021 17:12:30 +0000

Hi Jie,

Inline [TS_3]

From: Dongjie (Jimmy) <[email-masked]>
Date: Monday, November 8, 2021 at 11:40 AM
To: Tarek Saad <[email-masked]>, Wubo (lana) <[email-masked]>, Tarek Saad <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

Hi Tarek,

Hi Bo,

See inline [TSTS]..

Hi Tarek,

Thanks,
Bo

Hi Jie,

See below.

[Jie #2] The traffic flows are grouped by different network slices. According to the previous discussion on the multiple connectivity matrix and SLOs in a slice, it is assumed that the flows in the same slice may have different SLOs. Following this, the flows which belong to one slice aggregate may come from different slices. Then more precisely it should be called “slice traffic/flow aggregate”. This was also raised before during mail list discussion.
[TS_3]: for brevity, personally I prefer to keep it as slice aggregate. The definition is clear that is it a collection of slice traffic streams.

[Jie #2] Following Bo’s comment, as the ns-matching-criteria is for the matching of an individual network slice service, should there also be the matching criteria for slice aggregate in the NS Service YANG model?  Or what would be the mechanism to match slice traffic flows into a slice aggregate in the controller?
[TS_3]: as mentioned in introduction of draft-bestbar-teas-ns-packet, the mapping of multiple slice traffic streams (that have common SLOs) to a slice aggregate can be a function of the NSC (part of the processing the NS NBI request) and is usually done in conjunction with some capacity planning validation to see if aggregation will fit into the existing NRP.

The mechanism you described about the forwarding treatment on the packet is performed by network nodes involved in a network resource partition based on the identifier of the resource partition in the packet, which is after the traffic flows are mapped to the resource partition. I hope this is not mixed up with the procedure of mapping the network slice flows to the slice aggregate.
[TS_3]: Yes, the specific traffic streams that are part of the slice aggregate will leverage the usual service steering constructs to instruct the ingress to carry the specific selector of slice aggregate on the selected traffic streams.

Regards,
Tarek

Best regards,
Jie

Regards,
Tarek

Thanks for the update.

Best regards,
Jie

Hi WG,

  *   Several nit edits

Abstract:

The IETF Secretariat

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 8 Nov 2021 18:23:12 +0000 (UTC)

Hi Tarek,
I think Jie has a point. If a netwok slice is configured with more than one connectivity matrices, some with different SLOs, than it would be possible that two flows of the same network slice service sharing the same sender/receiver would have to be treated differently ( i.e. belong to separate NC aggregates) even when going through the same nodes/links. A better term would be Network Slice Flow Aggregate/Group.
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Mon, Nov 8, 2021 at 12:13 PM, Tarek Saad<tsaad=[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Tarek Saad <[email-masked]>
Date: Tue, 9 Nov 2021 12:55:38 +0000

Hi Igor,

Indeed, our narrative has been (noted earlier on the list) that the slice aggregate can be formed from slice traffic streams that have common SLOs. The NSC cherry picks such slice traffic streams (possibly from different IETF network slices)  with awareness of their SLOs and groups them into one slice aggregate that results in instantiating a network resource partition.
We could have used a longer descriptive name for slice aggregate (and maybe an acronym to go with it), but we chose to keep it short.

Regards,
Tarek

From: Igor Bryskin <[email-masked]>
Date: Monday, November 8, 2021 at 1:23 PM
To: tsaad=[email-masked] <tsaad=[email-masked]>, Tarek Saad <tsaad=[email-masked]>, Dongjie (Jimmy) <[email-masked]>, Wubo (lana) <[email-masked]>, Tarek Saad <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt
Hi Tarek,

Cheers,
Igor
Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Mon, Nov 8, 2021 at 12:13 PM, Tarek Saad
<tsaad=[email-masked]> wrote:
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 9 Nov 2021 14:53:53 +0000 (UTC)

Hi Tarek,
I understand your logic. My issue is that the term Network Slice Aggregate is confusing.  You expect X Aggregate to be a superset of Xs. You certainly do not expect a particular X to appear in multiple X Aggregates. As of now  a node/link may see multiple Network Slice Aggregates each for a separate flow of the same Network Slice Service. Therefore, a better term would be Network Slice Flow Aggregate (NSFA) or Group (NSFG).
Igor    On Tuesday, November 9, 2021, 07:55:56 AM EST, Tarek Saad <[email-masked]> wrote:  
 
 <!--#yiv4299382049 _filtered {} _filtered {} _filtered {} _filtered {}#yiv4299382049 #yiv4299382049 p.yiv4299382049MsoNormal, #yiv4299382049 li.yiv4299382049MsoNormal, #yiv4299382049 div.yiv4299382049MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv4299382049 a:link, #yiv4299382049 span.yiv4299382049MsoHyperlink {color:blue;text-decoration:underline;}#yiv4299382049 span.yiv4299382049EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv4299382049 .yiv4299382049MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv4299382049 div.yiv4299382049WordSection1 {}-->
Hi Igor,

 

Regards,
 
Tarek

From:Igor Bryskin <[email-masked]>
 
Hi Tarek,

 
Cheers,
 
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 9 Nov 2021 15:13:46 +0000 (UTC)

Also what is the relevance of  Slice Selector (SS) for Network Slice Aggregate, especially, when applying to a slice with multiple connectivity matrices, each with different SLO set? It looks like the PHB is per flow irrespectively of which slice the flow belongs to. In fact, NSA could be assigned to a flow that has nothing to do with the network slicing, right?
    On Tuesday, November 9, 2021, 10:04:55 AM EST, Igor Bryskin <i_bryskin=[email-masked]> wrote:  
 
  Hi Tarek,
 
 <!--#yiv3903579565 filtered {}#yiv3903579565 filtered {}#yiv3903579565 filtered {}#yiv3903579565 filtered {}#yiv3903579565 p.yiv3903579565MsoNormal, #yiv3903579565 li.yiv3903579565MsoNormal, #yiv3903579565 div.yiv3903579565MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv3903579565 a:link, #yiv3903579565 span.yiv3903579565MsoHyperlink {color:blue;text-decoration:underline;}#yiv3903579565 span.yiv3903579565EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv3903579565 .yiv3903579565MsoChpDefault {font-size:10.0pt;}#yiv3903579565 filtered {}#yiv3903579565 div.yiv3903579565WordSection1 {}-->
Hi Igor,

 

Regards,
 
Tarek

 
Hi Tarek,

 
Cheers,
 
Igor

---

From: Tarek Saad <[email-masked]>
Date: Tue, 16 Nov 2021 19:28:29 +0000

Hi Igor,

Thanks for the feedback. We have updated the draft to address this concern.
The latest revision is at https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-05

Regards,
Tarek (for co-authors)

From: Igor Bryskin <i_bryskin=[email-masked]>
Date: Tuesday, November 9, 2021 at 9:54 AM
To: Tarek Saad <[email-masked]>, Dongjie (Jimmy) <[email-masked]>, Wubo (lana) <[email-masked]>, [email-masked] <[email-masked]>, Tarek Saad <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

Hi Tarek,

Igor
On Tuesday, November 9, 2021, 07:55:56 AM EST, Tarek Saad <[email-masked]> wrote:

Hi Igor,

Regards,

Tarek

Hi Tarek,

Cheers,

Igor

Sent from Yahoo Mail on Android<https://urldefense.com/v3/__https:/go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature__;!!NEt6yMaO-gk!RTq8-V9hBqNJidkqC-6Sth8urMQ1m1lYgGuNR5l_lrExMziec1kb7GxtXvKsmQ$>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RTq8-V9hBqNJidkqC-6Sth8urMQ1m1lYgGuNR5l_lrExMziec1kb7Gw8Hs4HwA$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RTq8-V9hBqNJidkqC-6Sth8urMQ1m1lYgGuNR5l_lrExMziec1kb7Gw8Hs4HwA$>