Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

From: "Susan Hares" <[email-masked]>
Date: Sat, 4 Mar 2017 10:31:46 -0500

Shitanshu: 

Please address Ron's comment about widely deployed.  I believe this was part
of Alvaro's comments. 

Sue 

From: rtg-dir [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

The draft is internally consistent. But given what is left out of scope, I
wonder if the new attributes will ever be widely deployed.

Ron

This document might benefit from discussion of operational issues. I assume
that when a BGP listener learns a route with the SLA Exchange Attribute, it
provisions class of service forwarding classes on interfaces.

##svshah, though this is one desired use of exchanging SLA content, the
draft focuses on transporting SLA content from the SLA Producer to the SLA
Consumer. Processing of the QoS attribute content, at the SLA Consumer, is
outside the scope of this document.

##svshah, Let me know if you have a suggestion to make description clearer
in Section 1 and 2 to highlight this.

I also assume that a) it takes time to provision class of service forwarding
classes and b) the number of forwarding classes that can be provisioned are
finite. What does the BGP listener do when the number of forwarding classes
requested exceeds its capacity to deliver? 

##svshah, Since scope of the document is to transport SLA content from the
SLA Producer to the SLA Consumer, the document considers error handling in
the context of transporting data and thus any formating errors and semantics
errors within that context. Any errors in the context of processing QoS
attribute content at the SLA Consumer is outside the scope of the document.

---

From: Shitanshu Shah <[email-masked]>
Date: Mon, 6 Mar 2017 15:30:47 +0000

Hi Sue,

Following is what I had responded to Ron. Hopefully that addresses/clarifies.

To break it down in two point response,

1) This draft is not changing how SLA is established at first place. The draft is providing a method to convey this a priori established SLA to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devices should be capable to support that established SLA.

2) If there still are any issues in implementing exchanged SLA in forwarding, we think they either are implementation specific or of temporary nature where for example enough resources not available at any specific point of a time.

We feel that in current state of the draft, it can be largely useful in deployments.

One can imagine though even establishment of SLA also can be done via exchanging it over bgp. However, negotiation of SLA does not have to be clubbed with exchange of SLA. Negotiation of SLA is not in this scope.

Regards,
Shitanshu

________________________________
From: Susan Hares <[email-masked]>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Shitanshu:

Please address Ron’s comment about widely deployed.  I believe this was part of Alvaro’s comments.

Sue

From: rtg-dir [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed.

                                                                                Ron

This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces.

##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this.

I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver?

##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Mar 2017 11:24:02 -0500

Shitanshu: 

Ron is discussing your point #2 - you need to engage him on issue #2.    You
can provide input from operators who indicate this is necessary, but it is
important to have this discussion.  Alvaro was concerned about the
deployments of these attributes. 

Sue 

From: Shitanshu Shah [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 10:31 AM
To: Susan Hares; 'Ron Bonica'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Sue,

Following is what I had responded to Ron. Hopefully that
addresses/clarifies.

1) This draft is not changing how SLA is established at first place. The
draft is providing a method to convey this a priori established SLA to help
reduce lot of manual complexities and errors to admin. Thus given a
knowledge of what SLA is established, in general devices should be capable
to support that established SLA.

2) If there still are any issues in implementing exchanged SLA in
forwarding, we think they either are implementation specific or of temporary
nature where for example enough resources not available at any specific
point of a time.

We feel that in current state of the draft, it can be largely useful in
deployments.

One can imagine though even establishment of SLA also can be done via
exchanging it over bgp. However, negotiation of SLA does not have to be
clubbed with exchange of SLA. Negotiation of SLA is not in this scope.

Regards,

Shitanshu

  _____  

To: 'Ron Bonica'; 'Shitanshu Shah'; [email-masked];

Shitanshu: 

Sue 

Hello,

 
Ron

---

From: Keyur Patel <[email-masked]>
Date: Tue, 7 Mar 2017 19:53:06 +0000

Hi Sue, Ron, Alvaro,

As Shitanshu has stated in #2 that issues in implementing SLAs in forwarding are mostly implementation specific. To that point, we could add text suggesting that sufficient logging should be done so as to allow operators to intervene and solve the issue.  Would that be sufficient?

Please advise.

Regards,
Keyur

From: Susan Hares <[email-masked]>
Date: Monday, March 6, 2017 at 8:24 AM
To: 'Shitanshu Shah' <[email-masked]>, 'Ron Bonica' <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Monday, March 6, 2017 at 8:29 AM

Shitanshu:

Ron is discussing your point #2 – you need to engage him on issue #2.    You can provide input from operators who indicate this is necessary, but it is important to have this discussion.  Alvaro was concerned about the deployments of these attributes.

Sue

From: Shitanshu Shah [mailto:[email-masked]]
Sent: Monday, March 6, 2017 10:31 AM
To: Susan Hares; 'Ron Bonica'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Sue,

Regards,
Shitanshu

________________________________
From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Shitanshu:

Sue

From: rtg-dir [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

                                                                                Ron

---

From: "Tomotaki, Luis M" <[email-masked]>
Date: Tue, 7 Mar 2017 23:10:51 -0500

Ron and Sue,
>From a service provider perspective, exchanging the SLA information between the PE and CE would be very beneficial and could be widely used.  I think this is particular important in service provider's L3VPN networks where the customers or service providers currently do not have full visibility to the QoS policy in the other end of the connection but still needs matching CE-PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this example, once the SLA information exchange is standardized, my expectation is that the different CE/PE vendors would be able to automatically update in a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP.

Luis

From: Shitanshu Shah [mailto:[email-masked]]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <[email-masked]>; 'Ron Bonica' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Please address Ron's comment about widely deployed.  I believe this was part of Alvaro's comments.

Sue

Hello,

                                                                                Ron

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Mar 2017 10:22:33 -0500

Luis: 

Thank you for letting me know you desire for this feature.   Since Ron had
additional questions, I'll let him start off this discussion. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Ron and Sue,

>From a service provider perspective, exchanging the SLA information between
the PE and CE would be very beneficial and could be widely used.  I think
this is particular important in service provider's L3VPN networks where the
customers or service providers currently do not have full visibility to the
QoS policy in the other end of the connection but still needs matching CE-PE
SLA/QoS policies to achieve the correct two-way traffic prioritization
behavior during congestion.  In this example, once the SLA information
exchange is standardized, my expectation is that the different CE/PE vendors
would be able to automatically update in a vendor specific way, the SLA/QoS
policies based on the SLA information provided via BGP.  

Luis

From: Shitanshu Shah [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <[email-masked]>; 'Ron Bonica' <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Sue,

 

 

Regards,

Shitanshu

  _____  

Shitanshu: 

Sue 

Hello,

 
Ron

---

From: Ron Bonica <[email-masked]>
Date: Sun, 12 Mar 2017 16:11:14 +0000

Luis,

This discussion might require a slightly higher bandwidth channel. Feel free to call me whenever you get a chance.

                                                                 Ron
                                                                  571 203 1704

From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - [email-masked] <[email-masked]>; 'Shitanshu Shah' <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis:

Thank you for letting me know you desire for this feature.   Since Ron had additional questions, I'll let him start off this discussion.

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Ron and Sue,

Luis

From: Shitanshu Shah [mailto:[email-masked]]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Ron Bonica' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Sue

Hello,

                                                                                Ron

---

From: "Tomotaki, Luis M" <[email-masked]>
Date: Tue, 14 Mar 2017 12:52:43 -0400

Hi Ron,
Are you available for a quick call on Thursday at 10AM CT?

Luis

From: Ron Bonica [mailto:[email-masked]]
Sent: Sunday, March 12, 2017 11:11 AM
To: Susan Hares <[email-masked]>; Tomotaki, Luis M <[email-masked]>; 'Shitanshu Shah' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [E] RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis,

                                                                 Ron
                                                                  571 203 1704

From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; 'Shitanshu Shah' <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis:

Sue

Ron and Sue,

Luis

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Sue

Hello,

                                                                                Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 14 Mar 2017 17:03:58 +0000

Yes. I will send you a meeting invite. Feel free to forward it.

                             Ron

From: Tomotaki, Luis M [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 12:53 PM
To: Ron Bonica <[email-masked]>; Susan Hares <[email-masked]>; 'Shitanshu Shah' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Hi Ron,

Luis

From: Ron Bonica [mailto:[email-masked]]
Sent: Sunday, March 12, 2017 11:11 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; Tomotaki, Luis M <[email-masked]<mailto:[email-masked]>>; 'Shitanshu Shah' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [E] RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis,

                                                                 Ron
                                                                  571 203 1704

Luis:

Sue

Ron and Sue,

Luis

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Sue

Hello,

                                                                                Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 20 Mar 2017 13:29:32 +0000

Folks,

Luis and I spoke on Friday. The following is a summary of our conversation:

Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP speaker associates a forwarding policy with a prefix. When a BGP listener receives an advertisement that is associated with a policy, it:

-          Instantiates the policy, if it does not already exist

-          Associates the prefix with the policy

BGP listeners can instantiate a finite number of policies (N).  SO, what happens when a BGP listener has N policies instantiated and it receives an advertisement that would normally cause it to instantiate another policy? Options are:

-          Tear down the session

-          Discard the advertisement

-          Install the route, but without the advertisement

-          Do something else?

We should probably be explicit about the required behavior.

                                                                     Ron

From: Ron Bonica
Sent: Sunday, March 12, 2017 12:11 PM
To: 'Susan Hares' <[email-masked]>; EXT - [email-masked] <[email-masked]>; 'Shitanshu Shah' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis,

                                                                 Ron
                                                                  571 203 1704

Luis:

Sue

Ron and Sue,

Luis

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Sue

Hello,

                                                                                Ron

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Mar 2017 15:04:48 +0100

Hi Ron,

The behaviour in the case you are bringing up could be a local policy.

* ignore-when-overlap
* overwrite-when-overlap

Overlap means with local policy. Optionally you also can have a route map
attach to both and apply such policy on a per prefix basis.

Cheers
R.

On Mar 20, 2017 2:29 PM, "Ron Bonica" <[email-masked]> wrote:

> Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP
> speaker associates a forwarding policy with a prefix. When a BGP listener
> receives an advertisement that is associated with a policy, it:
>
>
>
> BGP listeners can instantiate a finite number of policies (N).  SO, what
> happens when a BGP listener has N policies instantiated and it receives an
> advertisement that would normally cause it to instantiate another policy?
> Options are:
>
>
>
> -          Tear down the session
>
> *From:* Ron Bonica
> *Sent:* Sunday, March 12, 2017 12:11 PM
> *To:* 'Susan Hares' <[email-masked]>; EXT - [email-masked] <
> [email-masked]>; 'Shitanshu Shah' <[email-masked]>;
> *Subject:* RE: [Idr] [RTG-DIR] RtgDir review:
> draft-ietf-idr-sla-exchange-10
>
>
>
> Luis,
>
>
>
> This discussion might require a slightly higher bandwidth channel. Feel
> free to call me whenever you get a chance.
>
>
>
>                                                                  Ron
>
>                                                                   571 203
> 1704 <(571)%20203-1704>
>
>
>
>
>
> *From:* Susan Hares [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, March 8, 2017 10:23 AM
> *To:* EXT - [email-masked] <[email-masked]>;
> 'Shitanshu Shah' <[email-masked]>; Ron Bonica <
> [email-masked]>; [email-masked]; draft-ietf-idr-sla-exchange.
> [email-masked]; [email-masked]
> *Subject:* RE: [Idr] [RTG-DIR] RtgDir review:
> draft-ietf-idr-sla-exchange-10
>
>
>
> Luis:
>
>
>
> additional questions, I’ll let him start off this discussion.
>
>
>
> Sue
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tomotaki, Luis M
> *Sent:* Tuesday, March 7, 2017 11:11 PM
> *To:* Shitanshu Shah; Susan Hares; 'Ron Bonica'; [email-masked];
> *Subject:* Re: [Idr] [RTG-DIR] RtgDir review:
> draft-ietf-idr-sla-exchange-10
>
>
>
> Ron and Sue,
>
> From a service provider perspective, exchanging the SLA information
> between the PE and CE would be very beneficial and could be widely used.  I
> think this is particular important in service provider’s L3VPN networks
> where the customers or service providers currently do not have full
> visibility to the QoS policy in the other end of the connection but still
> needs matching CE-PE SLA/QoS policies to achieve the correct two-way
> traffic prioritization behavior during congestion.  In this example, once
> the SLA information exchange is standardized, my expectation is that the
> different CE/PE vendors would be able to automatically update in a vendor
> specific way, the SLA/QoS policies based on the SLA information provided
> via BGP.
>
>
>
> Luis
>
>
>
> *From:* Shitanshu Shah [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, March 6, 2017 9:31 AM
> *To:* Susan Hares <[email-masked]>; 'Ron Bonica' <[email-masked]>;
> *Subject:* [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
>
>
>
> Hi Sue,
>
>
>
> forwarding, we think they either are implementation specific or of
> temporary nature where for example enough resources not available at any
> specific point of a time.
>
>
>
> ------------------------------
>
> *From:* Susan Hares <[email-masked]>
> *Sent:* Saturday, March 4, 2017 8:31 AM
> *To:* 'Ron Bonica'; 'Shitanshu Shah'; [email-masked];
> *Subject:* RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
>
>
>
> Shitanshu:
>
>
>
> *From:* rtg-dir [mailto:[email-masked]
> <[email-masked]>] * On Behalf Of *Ron Bonica
> *Sent:* Thursday, February 23, 2017 12:07 PM
> *To:* Shitanshu Shah; [email-masked]; draft-ietf-idr-sla-exchange.
> [email-masked]; [email-masked]
> *Subject:* Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
>
>
>
> Hello,
>
>
>
> This document might benefit from discussion of operational issues. I
> assume that when a BGP listener learns a route with the SLA Exchange
> Attribute, it provisions class of service forwarding classes on interfaces.
>
>
>
> I also assume that a) it takes time to provision class of service
> forwarding classes and b) the number of forwarding classes that can be
> provisioned are finite. What does the BGP listener do when the number of
> forwarding classes requested exceeds its capacity to deliver?
>
>
>
> the context of transporting data and thus any formating errors and
> semantics errors within that context. Any errors in the context of
> processing QoS attribute content at the SLA Consumer is outside the scope
> of the document.
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Mar 2017 11:50:27 -0400

Ron: 

Thank you for taking the time to talk with Luis, and for giving us the
concise and informative summary. 

Sue 

From: Ron Bonica [mailto:[email-masked]] 
Sent: Monday, March 20, 2017 9:30 AM
To: Susan Hares; EXT - [email-masked]; 'Shitanshu Shah';
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Folks,

Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP speaker
associates a forwarding policy with a prefix. When a BGP listener receives
an advertisement that is associated with a policy, it:

-          Tear down the session

-          Do something else?

                                                                     Ron

From: Ron Bonica 
Sent: Sunday, March 12, 2017 12:11 PM
To: 'Susan Hares' <[email-masked]>; EXT - [email-masked]
<[email-masked]>; 'Shitanshu Shah' <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis,

This discussion might require a slightly higher bandwidth channel. Feel free
to call me whenever you get a chance.

                                                                 Ron

                                                                  571 203
1704

From: Susan Hares [mailto:[email-masked]] 
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - [email-masked] <[email-masked]>; 'Shitanshu
Shah' <[email-masked]>; Ron Bonica <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Luis: 

Sue 

Ron and Sue,

Luis

Hi Sue,

 

 

Regards,

Shitanshu

  _____  

Shitanshu: 

Sue 

Hello,

 
Ron

---

From: Shitanshu Shah <[email-masked]>
Date: Wed, 22 Mar 2017 23:20:58 +0000

Hi Ron,

Thank you for your time and discussion with Luis.

When SLA (now called TCA) consumer receives an advertisement, the consumer SHOULD install the route  without TCA specific advertised attribute in the case it can not process TCA attribute. We will make it explicit in the document.

If you have suggestion on a specific section where it should go and/or if have a suggestion on a text, please suggest.

Regards,

Shitanshu

________________________________
From: Ron Bonica <[email-masked]>
Sent: Monday, March 20, 2017 7:29 AM
To: Susan Hares; EXT - [email-masked]; 'Shitanshu Shah'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

Folks,

-          Tear down the session

-          Do something else?

                                                                     Ron

From: Ron Bonica

Luis,

                                                                 Ron
                                                                  571 203 1704

Luis:

Thank you for letting me know you desire for this feature.   Since Ron had additional questions, I’ll let him start off this discussion.

Sue

Ron and Sue,
>From a service provider perspective, exchanging the SLA information between the PE and CE would be very beneficial and could be widely used.  I think this is particular important in service provider’s L3VPN networks where the customers or service providers currently do not have full visibility to the QoS policy in the other end of the connection but still needs matching CE-PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this example, once the SLA information exchange is standardized, my expectation is that the different CE/PE vendors would be able to automatically update in a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP.

Luis

Hi Sue,

Regards,
Shitanshu

Shitanshu:

Sue

Hello,

                                                                                Ron