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

"Susan Hares" <> Mon, 06 March 2017 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7205129540; Mon, 6 Mar 2017 08:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CtM5BlReGbkW; Mon, 6 Mar 2017 08:29:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A78931294F5; Mon, 6 Mar 2017 08:29:05 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Shitanshu Shah' <>, 'Ron Bonica' <>,,,
References: <> <> <>, <053401d294fc$6f739180$4e5ab480$> <>
In-Reply-To: <>
Date: Mon, 06 Mar 2017 11:24:02 -0500
Message-ID: <00b401d29696$11e5a850$35b0f8f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01D2966C.2912FBB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjQJ00uVDAja9hsUCLb3BQwJAbTEloOe2COA=
Content-Language: en-us
Archived-At: <>
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Mar 2017 16:29:07 -0000



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. 




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


Hi Sue,


Following is what I had responded to Ron. Hopefully that


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




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.






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




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




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




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





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.