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

Keyur Patel <keyur@arrcus.com> Tue, 07 March 2017 19:53 UTC

Return-Path: <keyur@arrcus.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7012948D; Tue, 7 Mar 2017 11:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wftV5bJ1hA76; Tue, 7 Mar 2017 11:53:17 -0800 (PST)
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B4A129426; Tue, 7 Mar 2017 11:53:17 -0800 (PST)
Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 658068006E; Tue, 7 Mar 2017 19:53:16 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx6-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 49E3B60058; Tue, 7 Mar 2017 19:53:16 +0000 (UTC)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx6-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 397D44C0077; Tue, 7 Mar 2017 19:53:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjhl5XVbwIO8wSAV1Qz0GquTXU+GjOCK2SZ44sb1d8I=; b=a6GyhBAfd+rnmooHW4Is3dAJ/VCVUAXtow2GXoPy6d4AV8fo1YWvngHwiRPDnZR8s8WtvbOs8UqNo8FZcJK7qD2JMG21Tx2jDcYYNcvmKFYr4d8iTERXmUHEJIM46ckHl9vtlBpkpU6WMabIqhYhAoZQ2+E5SB2OPFeYaNO3nME=
Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.14; Tue, 7 Mar 2017 19:53:07 +0000
Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 19:53:07 +0000
From: Keyur Patel <keyur@arrcus.com>
To: Susan Hares <shares@ndzh.com>, 'Shitanshu Shah' <shitanshu_shah@hotmail.com>, 'Ron Bonica' <rbonica@juniper.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-sla-exchange.all@ietf.org" <draft-ietf-idr-sla-exchange.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAAHoygAAKNQfgA==
Date: Tue, 07 Mar 2017 19:53:06 +0000
Message-ID: <A99C2EDD-D742-4DCD-A0B9-3E249449078E@arrcus.com>
References: <BLUPR0501MB205181BB8965FA5353E28162AE5A0@BLUPR0501MB2051.namprd05.prod.outlook.com> <DM3PR13MB060413F4B03D932E5E6BE75DE55D0@DM3PR13MB0604.namprd13.prod.outlook.com> <BLUPR0501MB20518C25229CB24F15458B4CAE530@BLUPR0501MB2051.namprd05.prod.outlook.com> <053401d294fc$6f739180$4e5ab480$@ndzh.com> <DM3PR13MB0604AC6594DBE7B40707F528E52C0@DM3PR13MB0604.namprd13.prod.outlook.com> <00b401d29696$11e5a850$35b0f8f0$@ndzh.com>
In-Reply-To: <00b401d29696$11e5a850$35b0f8f0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=arrcus.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [96.68.143.133]
x-ms-office365-filtering-correlation-id: ce6b79e8-206d-46da-7cfd-08d465939348
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0263;
x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:7AEKkrHLSj1/xmhEGCbeWEVAu/eym+Dix5j2ZY5VVmF+zp8AzEhUt6xuYAYg0iJ/hfjnaatdZvPbLo305+Ze2iY1pvcNlfKZYV7lJLIT5SUkf38XMT8j/iLn54IabRyehjiqZk0s+TCQNWMFY5G31WuMbmQ6GjGe7F6frkEo257HBCK3gwXOyz11w77TIudmHIS3BOO/M3nUOiArdymKflKhDWEfUjNazXseUczAlENYTlfu37p0cw8S6p0fz+29LcEBj4PFbX0P53qdO2YfU3FnnHYSUFKKpLB+PC7KJqsDYwxf4ZeXYJM6PuGoe8Dm+sWfkKC9QK5QjohXtpgXlA==
x-microsoft-antispam-prvs: <BY2PR18MB02638B40104DD5A46287ADAAC12F0@BY2PR18MB0263.namprd18.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(97927398514766)(95692535739014)(18271650672692)(194151415913766)(21748063052155)(154440410675630)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39410400002)(39450400003)(54094003)(377454003)(3846002)(93886004)(39060400002)(3660700001)(38730400002)(2906002)(86362001)(6246003)(230783001)(6116002)(53546006)(6506006)(2900100001)(3280700002)(189998001)(2501003)(8676002)(1941001)(2950100002)(102836003)(66066001)(53936002)(25786008)(81166006)(8666007)(122556002)(77096006)(83716003)(2201001)(76176999)(50986999)(6486002)(6436002)(54356999)(229853002)(82746002)(5660300001)(36756003)(33656002)(7736002)(6512007)(99286003)(6306002)(54896002)(8936002)(236005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_A99C2EDDD7424DCDA0B93E249449078Earrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 19:53:06.8869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263
X-MDID: 1488916396-ciskaKmhPV07
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/y8IqqA4Rl2dVZaknzZIhkEuy8Ng>
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 19:53:19 -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 <shares@ndzh.com>
Date: Monday, March 6, 2017 at 8:24 AM
To: 'Shitanshu Shah' <shitanshu_shah@hotmail.com>, 'Ron Bonica' <rbonica@juniper.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-sla-exchange.all@ietf.org" <draft-ietf-idr-sla-exchange.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
Resent-From: <alias-bounces@ietf.org>
Resent-To: <luis.tomotaki@verizon.com>, <mohamed.boucadair@orange.com>, <shitanshu_shah@hotmail.com>, <keyur@arrcus.com>, <sbajaj@juniper.net>, <jgs@juniper.net>, <shares@ndzh.com>, <jie.dong@huawei.com>, <aretana@cisco.com>, <db3546@att.com>, <akatlas@gmail.com>, <skh@ndzh.com>
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:shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 10:31 AM
To: Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
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.



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 <shares@ndzh.com<mailto:shares@ndzh.com>>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-idr-sla-exchange.all@ietf.org<mailto:draft-ietf-idr-sla-exchange.all@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
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:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-idr-sla-exchange.all@ietf.org<mailto:draft-ietf-idr-sla-exchange.all@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
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.