Subject: [Teas] Modelling VPNs in Network Slicing and Receiver SLOs

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Mar 2022 10:30:36 -0000

Hi,

The open question resulting from my long discussion with Luis concerns how
you model complex services and whether this requires the use of "receiver
SLOs".

We seemed to arrive at two possible motivations:

1. A sender is sending traffic volume N, but may break that into Na, Nb, and
Nc (Na+Nb+Nc <= N) to three different receivers, and may vary those three
volumes over time. It is possible for the sender to have three P2P
connectivity constructs with volume SLO set to N on each, but this may be
expensive and not completely helpful to the provider.

An option here is to have a "meta SLO" that spans multiple connectivity
constructs. Thus, we could express that the sum of the volume across all
three constructs will never be more than N, but the peak on any one
construct could also be N. (Presumably, the provider would police or provide
admission control.)

Another option is to use an A2A construct which leads to...

2. A customer wants to model a VPN service (such as L3VPN) in network
slicing. They do this using an A2A connectivity construct so that the
provider knows that there may be traffic from any SDP to any other SDP. The
sender SLOs tell the provider the volume from each sender, but not the
volume to each receiver.

It is possible that knowledge of the receiver AC capabilities is enough. It
may be that the "excess" traffic at the receiver is just discarded. Or it
may be that some form of receiver SLO is useful.

How do people who want to model VPNs in network slicing do this today?

Thanks,
Adrian

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 12:17:19 +0000

Hi Adrian, all,

I would just go for the following:

* vpn-service-topology=any-to-any 
* set the following for each for each SDP: 
                    +--rw service
                   |  +--rw svc-input-bandwidth     uint64
                   |  +--rw svc-output-bandwidth    uint64 

These values are included in the service request, and not set by the provider by some magic. 

If many SDPs are sending to the same SDP, there is a risk that the incoming capacity for a given SDP will be exceeded but that's up to the customer to appropriate quantify the need. The following from the framework will be then applied: 

      Excess traffic is dropped by
      default, unless specific out-of-profile policies are agreed
      between the customer and the provider.

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Adrian Farrel
> Envoyé : mardi 22 mars 2022 11:31
> À : [email-masked]
> Objet : [Teas] Modelling VPNs in Network Slicing and Receiver SLOs
> 
> Hi,
> 
> The open question resulting from my long discussion with Luis concerns
> how you model complex services and whether this requires the use of
> "receiver SLOs".
> 
> 1. A sender is sending traffic volume N, but may break that into Na, Nb,
> and Nc (Na+Nb+Nc <= N) to three different receivers, and may vary those
> three volumes over time. It is possible for the sender to have three P2P
> connectivity constructs with volume SLO set to N on each, but this may
> be expensive and not completely helpful to the provider.
> 
> construct could also be N. (Presumably, the provider would police or
> provide admission control.)
> 
> provider knows that there may be traffic from any SDP to any other SDP.
> The sender SLOs tell the provider the volume from each sender, but not
> the volume to each receiver.
> 
> It is possible that knowledge of the receiver AC capabilities is enough.
> It may be that the "excess" traffic at the receiver is just discarded.
> Or it may be that some form of receiver SLO is useful.
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 22 Mar 2022 13:36:34 +0100

Hi,

Couple of points:

a) input BW, and output BW per SDP in the same slice service can be different, so knowledge of the receiver AC capabilities only (without sender) is not enough
b) in A2A construct (such as L3VPN) SDPs can have different capacity requirements: i.e. we could have few categories of of SDPs: small, medium, large, with different capacity requirements. So, no uniform SLO for all SDPs
c) typically, we use multiple classes, so simple parameter input/output BW per AC is not sufficient, and there should be possibility to specify input/output QoS profile, which includes multiple classes
d) rates should have possibility to specify CIR (minimum guaranteed rate) and optionally PIR (maximum rate), where

<CIR -> traffic always passes trough (guaranteed traffic)
> CIR, <PIR -> traffic as allowed at the ingress SDP, but might be dropped somewhere in the network (i.e., not guaranteed to be delivered)
> PIR -> traffic is dropped right at ingress SDP

Cheers,
Krzysztof

> On 2022 -Mar-22, at 13:17, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Adrian, all,
>

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 12:58:19 +0000

Re-,

(a) and (b) can be met by adequately setting the in/out value for each SDP (access). 
(c) and part of (d) can be met by setting the qos profile at both the service level and per access 

                   |  |                 +--rw bandwidth
                   |  |                    +--rw guaranteed-bw-percent

We do have a more rich set tweaks to meet (d) in the L2nm as we can specific for each SDP the following: 

                                 +--rw svc-pe-to-ce-bandwidth
                                 |       {vpn-common:inbound-bw}?
                                 |  +--rw pe-to-ce-bandwidth* [bw-type]
                                 |     +--rw bw-type   identityref
                                 |     +--rw cos-id?   uint8
                                 |     |       {vpn-common:qos}?
                                 |     +--rw cir?      uint64
                                 |     +--rw cbs?      uint64
                                 |     +--rw eir?      uint64
                                 |     +--rw ebs?      uint64
                                 |     +--rw pir?      uint64
                                 |     +--rw pbs?      uint64
                                 +--rw svc-ce-to-pe-bandwidth
                                 |       {vpn-common:outbound-bw}?
                                 |  +--rw ce-to-pe-bandwidth* [bw-type]
                                 |     +--rw bw-type   identityref
                                 |     +--rw cos-id?   uint8
                                 |     |       {vpn-common:qos}?
                                 |     +--rw cir?      uint64
                                 |     +--rw cbs?      uint64
                                 |     +--rw eir?      uint64
                                 |     +--rw ebs?      uint64
                                 |     +--rw pir?      uint64
                                 |     +--rw pbs?      uint64 

Cheers,
Med

> De : Krzysztof Szarkowicz <[email-masked]>
> Envoyé : mardi 22 mars 2022 13:37
> À : [email-masked]
> Cc : [email-masked]; BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>
> Objet : Re: [Teas] Modelling VPNs in Network Slicing and Receiver SLOs
> 
> Hi,
> 
> Couple of points:
> 
> a) input BW, and output BW per SDP in the same slice service can be
> different, so knowledge of the receiver AC capabilities only (without
> sender) is not enough
> b) in A2A construct (such as L3VPN) SDPs can have different capacity
> requirements: i.e. we could have few categories of of SDPs: small,
> medium, large, with different capacity requirements. So, no uniform SLO
> for all SDPs
> c) typically, we use multiple classes, so simple parameter input/output
> BW per AC is not sufficient, and there should be possibility to specify
> input/output QoS profile, which includes multiple classes
> d) rates should have possibility to specify CIR (minimum guaranteed
> rate) and optionally PIR (maximum rate), where
> 
> > CIR, <PIR -> traffic as allowed at the ingress SDP, but might be
> > dropped somewhere in the network (i.e., not guaranteed to be
> > delivered) PIR -> traffic is dropped right at ingress SDP
> 
> Cheers,
> Krzysztof
> 
> > If many SDPs are sending to the same SDP, there is a risk that the
> incoming capacity for a given SDP will be exceeded but that's up to the
> customer to appropriate quantify the need. The following from the
> framework will be then applied:
> >
> >> De : Teas <[email-masked]> De la part de Adrian Farrel Envoyé
> >> : mardi 22 mars 2022 11:31 À : [email-masked] Objet : [Teas] Modelling
> >> VPNs in Network Slicing and Receiver SLOs
> >>
> >> Hi,
> >>
> >> The open question resulting from my long discussion with Luis
> >> concerns how you model complex services and whether this requires the
> >> use of "receiver SLOs".
> >>
> >> 1. A sender is sending traffic volume N, but may break that into Na,
> >> Nb, and Nc (Na+Nb+Nc <= N) to three different receivers, and may vary
> >> those three volumes over time. It is possible for the sender to have
> >> three P2P connectivity constructs with volume SLO set to N on each,
> >> but this may be expensive and not completely helpful to the provider.
> >>
> >> An option here is to have a "meta SLO" that spans multiple
> >> connectivity constructs. Thus, we could express that the sum of the
> >> volume across all three constructs will never be more than N, but the
> >> peak on any one construct could also be N. (Presumably, the provider
> >> would police or provide admission control.)
> >>
> >> The sender SLOs tell the provider the volume from each sender, but
> >> not the volume to each receiver.
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.

---

From: "Simon Spraggs (sspraggs)" <[email-masked]>
Date: Tue, 22 Mar 2022 15:04:14 +0000

The construct adopted by many SPs for any-to-any service is use of the hose SLA model. This assumes the SLA / SLO is imposed at one end or both ends of the access circuit depending on whether the CE is present and whether it is managed or not. In an ideal world, on ingress the CE controls, marks and schedules traffic entering the network onto the AC and on egress the PE controls (shapes) and schedules, based on DSCP or traffic class, the traffic exiting the network. Not necessarily relevant to this discussion, the core links generally have basic QoS configured (which doesn’t change) but it is normally assumed that traffic isn’t dropped in standard operations and if dropped due to a failure or capacity planning issue is based on a prioritised diffserv model.  Ie high priority traffic is preserved to the determent of the lower priority traffic. Looking at common approaches used on access circuits. 
1) Input and egress bandwidth onto the AC. These can be different. In ingress this bandwidth is often policed, on egress it is often shaped. In both cases the overall bandwidth can be fixed or have a burst capability so the AC can expand based on the utilization of other ACs on the same physical interface. 
2) Within the AC. Further control occurs within the AC, typically based on the QoS markings within the packet. Again, this is based on policing or shaping different classes and each class can be fixed to an overall bandwidth or bandwidth % of the AC or much more commonly can burst above its rate when other traffic types are not present.  
3) Both these areas are complicated and often hardware implementation dependent. For this reason, many SPs have several abstract QoS profiles which they apply on the CE, PE or both, such as small, medium, large which hides much of the QoS complexity above.  

 Coming back to the question, should there be receiver SLOs. In my view, there should be, and it should be based on egress AC bandwidth and allocation of that bandwidth to different classes. These could be specified with a full set of QoS parameters associated with egress conditioning, scheduling etc or using an abstract QoS profile or both. In one case the model will include a huge amount of QoS configuration in the other the QoS profiles need to be set-up by something else. 
Cheers Simon   

On 22/03/2022, 10:31, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Mar 2022 11:13:37 -0400

There is, to my understanding, a distinction between an egress port 
property and a receiver property on a connectivity construct.  The 
former is useful.  The latter not so much.

For the example I have heard of a colelction of egress ports with a 
combined bandwidth and some limits that move among them, I don't think 
receiver SLO is the right representation.
Rather, since each receiver may be receiving a given amount of bandwidth 
some of the time (same or different across receivers) that is a 
collection of pt-to-pt connectivity constructs.

The argument I saw was that the total bandwidth limit was smaller than 
the total of the pt-to-pts.   That seems to correspond to an ingress 
property, not a receiver property or a connectivity construct.

The only interesting question I see is if there is a ingress limit for a 
collection of connectivity constructs from a given ingress.  If so, then 
we need to complicate the model for that.  I am a little concerned about 
adding that as it introduces a range of complexity for actual 
implementation (how many levels of hierarchical policing will we need.)

Yours,
Joel

---

From: Kiran M <[email-masked]>
Date: Tue, 22 Mar 2022 12:00:45 -0700

Hi,

Pulling up one point just to be sure that I understood correctly:
The only interesting question I see is if there is a ingress limit for a 
collection of connectivity constructs from a given ingress.
^^^
Is the complexity here number of 'point-to-point' connections?

If yes, then  it is a  scalability problem and  there will be many other 
types of limits on resources.

FWIW, I also prefer  pt-to-pt SLO as per Med's example over a new term 
'meta SLO'. The slicing model itself should be simple yet complete so 
that it is  easy to deploy. Right now I think A2A is way simpler to 
deploy and understand than meta SLO without any loss of functionality. 
Since, in my mind, one could implement meta-SLO via abstraction 
(hierarchical slice).

-Kiran

------------------------------------------------------------------------
*From:* Joel M. Halpern [mailto:[email-masked]]
*Sent:* Tuesday, March 22, 2022, 8:13 AM
*To:* Simon Spraggs (sspraggs); [email-masked]; [email-masked]
*Subject:* [Teas] Modelling VPNs in Network Slicing and Receiver SLOs

> Rather, since each receiver may be receiving a given amount of 
> bandwidth some of the time (same or different across receivers) that 
> is a collection of pt-to-pt connectivity constructs.
>
> The only interesting question I see is if there is a ingress limit for 
> a collection of connectivity constructs from a given ingress. If so, 
> then we need to complicate the model for that.  I am a little 
> concerned about adding that as it introduces a range of complexity for 
> actual implementation (how many levels of hierarchical policing will 
> we need.)
>
> Yours,
> Joel
>
>> The construct adopted by many SPs for any-to-any service is use of 
>> the hose SLA model. This assumes the SLA / SLO is imposed at one end 
>> or both ends of the access circuit depending on whether the CE is 
>> present and whether it is managed or not. In an ideal world, on 
>> ingress the CE controls, marks and schedules traffic entering the 
>> network onto the AC and on egress the PE controls (shapes) and 
>> schedules, based on DSCP or traffic class, the traffic exiting the 
>> network. Not necessarily relevant to this discussion, the core links 
>> generally have basic QoS configured (which doesn’t change) but it is 
>> normally assumed that traffic isn’t dropped in standard operations 
>> and if dropped due to a failure or capacity planning issue is based 
>> on a prioritised diffserv model.  Ie high priority traffic is 
>> preserved to the determent of the lower priority traffic. Looking at 
>> common approaches used on access circuits.
>> 1) Input and egress bandwidth onto the AC. These can be different. In 
>> ingress this bandwidth is often policed, on egress it is often 
>> shaped. In both cases the overall bandwidth can be fixed or have a 
>> burst capability so the AC can expand based on the utilization of 
>> other ACs on the same physical interface.
>> 2) Within the AC. Further control occurs within the AC, typically 
>> based on the QoS markings within the packet. Again, this is based on 
>> policing or shaping different classes and each class can be fixed to 
>> an overall bandwidth or bandwidth % of the AC or much more commonly 
>> can burst above its rate when other traffic types are not present.
>> 3) Both these areas are complicated and often hardware implementation 
>> dependent. For this reason, many SPs have several abstract QoS 
>> profiles which they apply on the CE, PE or both, such as small, 
>> medium, large which hides much of the QoS complexity above.
>>
>>   Coming back to the question, should there be receiver SLOs. In my 
>> view, there should be, and it should be based on egress AC bandwidth 
>> and allocation of that bandwidth to different classes. These could be 
>> specified with a full set of QoS parameters associated with egress 
>> conditioning, scheduling etc or using an abstract QoS profile or 
>> both. In one case the model will include a huge amount of QoS 
>> configuration in the other the QoS profiles need to be set-up by 
>> something else.
>> Cheers Simon
>>
>> On 22/03/2022, 10:31, "Teas on behalf of Adrian Farrel" 
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>      Hi,
>>
>> concerns how
>> connectivity

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Mar 2022 15:15:58 -0400

For Enhanced VPN w/ SLO and typical QOS for SLA  I would think A2A would be
the only one deployed.

As all VPNs are any to any connectivity I don’t see any of the others would
be applicable.

I wonder if it would make sense to map each connectivity construct to a
real world use case including other technologies such as 3GPP and even
optical and see what applications apply to the other constructs.  Also then
have corresponding yang model that maps to each construct and use case.

I think that would really help with the real world  realization of the
connectivity construct concept.

Thanks

Gyan

On Tue, Mar 22, 2022 at 3:01 PM Kiran M <[email-masked]> wrote:

> 'meta SLO'. The slicing model itself should be simple yet complete so that
> it is  easy to deploy. Right now I think A2A is way simpler to deploy and
> understand than meta SLO without any loss of functionality. Since, in my
> mind, one could implement meta-SLO via abstraction (hierarchical slice).
>
> -Kiran
>
> ------------------------------
> *From:* Joel M. Halpern [mailto:[email-masked] <[email-masked]>]
> property and a receiver property on a connectivity construct.  The former
> is useful.  The latter not so much.
>
> some of the time (same or different across receivers) that is a collection
> of pt-to-pt connectivity constructs.
>
> The argument I saw was that the total bandwidth limit was smaller than the
> total of the pt-to-pts.   That seems to correspond to an ingress property,
> not a receiver property or a connectivity construct.
>
> collection of connectivity constructs from a given ingress.  If so, then we
> need to complicate the model for that.  I am a little concerned about
> The construct adopted by many SPs for any-to-any service is use of the
> hose SLA model. This assumes the SLA / SLO is imposed at one end or both
> ends of the access circuit depending on whether the CE is present and
> whether it is managed or not. In an ideal world, on ingress the CE
> controls, marks and schedules traffic entering the network onto the AC and
> on egress the PE controls (shapes) and schedules, based on DSCP or traffic
> class, the traffic exiting the network. Not necessarily relevant to this
> discussion, the core links generally have basic QoS configured (which
> doesn’t change) but it is normally assumed that traffic isn’t dropped in
> standard operations and if dropped due to a failure or capacity planning
> issue is based on a prioritised diffserv model.  Ie high priority traffic
> is preserved to the determent of the lower priority traffic. Looking at
> ingress this bandwidth is often policed, on egress it is often shaped. In
> both cases the overall bandwidth can be fixed or have a burst capability so
> the AC can expand based on the utilization of other ACs on the same
> physical interface.
> 2) Within the AC. Further control occurs within the AC, typically based on
> the QoS markings within the packet. Again, this is based on policing or
> shaping different classes and each class can be fixed to an overall
> bandwidth or bandwidth % of the AC or much more commonly can burst above
> its rate when other traffic types are not present.
> dependent. For this reason, many SPs have several abstract QoS profiles
> which they apply on the CE, PE or both, such as small, medium, large which
> hides much of the QoS complexity above.
>
>   Coming back to the question, should there be receiver SLOs. In my view,
> there should be, and it should be based on egress AC bandwidth and
> allocation of that bandwidth to different classes. These could be specified
> with a full set of QoS parameters associated with egress conditioning,
> scheduling etc or using an abstract QoS profile or both. In one case the
> model will include a huge amount of QoS configuration in the other the QoS
> profiles need to be set-up by something else.
> Cheers Simon
>
> On 22/03/2022, 10:31, "Teas on behalf of Adrian Farrel" <[email-masked]
> on behalf of [email-masked]>
> <[email-masked]@olddog.co.uk> wrote:
>
>      Hi,
>
> Nb, and
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 23 Mar 2022 08:26:47 +0000

Hi All,

We also agree with Med, Kiran and Gyan.

I had thought a kind of "meta SLO" concept before, but have never implemented because of the complexity of the real-time distributed monitor and control.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Gyan Mishra
Sent: Wednesday, March 23, 2022 4:16 AM
To: Kiran M <[email-masked]>
Cc: [email-masked]; [email-masked]; sspraggs=[email-masked]
Subject: Re: [Teas] Modelling VPNs in Network Slicing and Receiver SLOs

For Enhanced VPN w/ SLO and typical QOS for SLA  I would think A2A would be the only one deployed.  

As all VPNs are any to any connectivity I don’t see any of the others would be applicable.

I wonder if it would make sense to map each connectivity construct to a real world use case including other technologies such as 3GPP and even optical and see what applications apply to the other constructs.  Also then have corresponding yang model that maps to each construct and use case.

I think that would really help with the real world  realization of the connectivity construct concept.

Thanks 

Gyan

On Tue, Mar 22, 2022 at 3:01 PM Kiran M <[email-masked] <mailto:[email-masked]> > wrote:

	Hi,

	Pulling up one point just to be sure that I understood correctly:
	The only interesting question I see is if there is a ingress limit for a collection of connectivity constructs from a given ingress. 
	
	^^^

	If yes, then  it is a  scalability problem and  there will be many other types of limits on resources.  

	FWIW, I also prefer  pt-to-pt SLO as per Med's example over a new term 'meta SLO'. The slicing model itself should be simple yet complete so that it is  easy to deploy. Right now I think A2A is way simpler to deploy and understand than meta SLO without any loss of functionality. Since, in my mind, one could implement meta-SLO via abstraction (hierarchical slice).

	-Kiran

________________________________

	From: Joel M. Halpern [mailto:[email-masked]]
	Sent: Tuesday, March 22, 2022, 8:13 AM
	To: Simon Spraggs (sspraggs); [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
	Subject: [Teas] Modelling VPNs in Network Slicing and Receiver SLOs

		There is, to my understanding, a distinction between an egress port property and a receiver property on a connectivity construct.  The former is useful.  The latter not so much. 
		
		For the example I have heard of a colelction of egress ports with a combined bandwidth and some limits that move among them, I don't think receiver SLO is the right representation. 
		Rather, since each receiver may be receiving a given amount of bandwidth some of the time (same or different across receivers) that is a collection of pt-to-pt connectivity constructs. 
		
		The argument I saw was that the total bandwidth limit was smaller than the total of the pt-to-pts.   That seems to correspond to an ingress property, not a receiver property or a connectivity construct. 
		
		The only interesting question I see is if there is a ingress limit for a collection of connectivity constructs from a given ingress.  If so, then we need to complicate the model for that.  I am a little concerned about adding that as it introduces a range of complexity for actual implementation (how many levels of hierarchical policing will we need.) 
		
		Yours, 
		Joel 

			
			
			On 22/03/2022, 10:31, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> <mailto:[email-masked]@olddog.co.uk>  wrote: 
			
			     Hi, 

			

			

			
			     Thanks, 
			     Adrian 
			
			     _______________________________________________ 
			     Teas mailing list 
			     [email-masked] <mailto:[email-masked]>  
			     https://www.ietf.org/mailman/listinfo/teas 
			
			_______________________________________________ 
			Teas mailing list 
			[email-masked] <mailto:[email-masked]>  
			https://www.ietf.org/mailman/listinfo/teas 

		_______________________________________________ 
		Teas mailing list 
		[email-masked] <mailto:[email-masked]>  
		https://www.ietf.org/mailman/listinfo/teas 

	_______________________________________________
	Teas mailing list
	[email-masked] <mailto:[email-masked]> 
	https://www.ietf.org/mailman/listinfo/teas

-- 

Gyan Mishra

Network Solutions Architect 

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

M 301 502-1347