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

Ron Bonica <> Mon, 20 March 2017 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 792F4129495; Mon, 20 Mar 2017 06:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9oOJwrz4wh7M; Mon, 20 Mar 2017 06:29:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9811B1270FC; Mon, 20 Mar 2017 06:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bJk46ZmVhj/OJDZEgpRZWSpXhMIPlzmwL9w2Gu+3RqU=; b=JvMqqHqiFqHTA5HJB+OKDmzFNIImaWz9QSTsssLNEipZU7rI2eA2bRLPPkXHdotwoCIcJFIddYtVVtGv1LVhYcV1kGw0VQOzHzrgJrsJw7M0bR6ANV8LO5ZvqSBvu4P4JxCMSe3SSBXmk9P3EsjU6aUC53xKfQRdVZsVCx1HoKA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 13:29:32 +0000
Received: from ([]) by ([]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 13:29:32 +0000
From: Ron Bonica <>
To: Susan Hares <>, "EXT -" <>, 'Shitanshu Shah' <>, "" <>, "" <>, "" <>
Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
Date: Mon, 20 Mar 2017 13:29:32 +0000
Message-ID: <>
References: <> <> <>, <053401d294fc$6f739180$4e5ab480$> <> <> <011601d2981f$cfe364c0$6faa2e40$>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:0d1dxxkpN+jUsF0/101t677slDp5oi9BpoN6mA4GCDrhyAmtrUVzXPqrgY1v3+IruSVmeSfC132EQgehMVcKLSmoQ2EV1KMEudaE5T6xt2mRNoKVSAPF2RAdXLIviGBf5Rwga0vVMejSmXkoFX1GTiSsUkpLz+Qa4h8s6pxqp1y4XVQiYfnqvuXBHw6tWyk8r7BQxSGNxwOvuOrxxJC8tdLVQR1eKGqlHeSmRfaPE/QnGdyyMNaQG2zkxqobZs10IuIQIkDSdVpMbug6za4brtrBXK5m5t0deeUJ3OUiuuyX+AunjIWjv6gWg317LCqxkUQMrht+fKJqW39squABzA==
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-ms-office365-filtering-correlation-id: bae9b0c8-4209-47b4-5a18-08d46f9524fb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BLUPR0501MB2051;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(138986009662008)(194151415913766)(21748063052155)(154440410675630);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051;
x-forefront-prvs: 02524402D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(377454003)(54094003)(3846002)(6116002)(229853002)(102836003)(790700001)(3280700002)(3660700001)(2906002)(33656002)(66066001)(76176999)(50986999)(54356999)(93886004)(5660300001)(122556002)(74316002)(7736002)(230783001)(189998001)(39060400002)(6246003)(2900100001)(38730400002)(8936002)(8676002)(53936002)(81166006)(7696004)(345774005)(6306002)(54896002)(6506006)(55016002)(99286003)(25786008)(236005)(77096006)(53946003)(2201001)(9686003)(2501003)(86362001)(6436002)(53546008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0BLUPR0501MB2051_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 13:29:32.4953 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051
Archived-At: <>
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 13:29:39 -0000


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.


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


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

                                                                  571 203 1704

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


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


From: Idr [] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica';<>;<>;<>
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.


From: Shitanshu Shah []
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <<>>; 'Ron Bonica' <<>>;<>;<>;<>
Subject: [E] 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.

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.


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.