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

Robert Raszuk <robert@raszuk.net> Mon, 20 March 2017 14:04 UTC

Return-Path: <rraszuk@gmail.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 E6902131491; Mon, 20 Mar 2017 07:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 q0ohqkUmykYS; Mon, 20 Mar 2017 07:04:51 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 7642E12949B; Mon, 20 Mar 2017 07:04:51 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id g138so96586176itb.0; Mon, 20 Mar 2017 07:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KTXpOKSzMIwkf9Xc/62ZswKipaYYrqY887dNNARFRIM=; b=vfFLDyZBMsCa0/WsznnLhuK2llkEWySLsnrUDscs0Dzvl3utHVRMXvllL12+mf8LTE +dgsR0nEUNc/FaHQq6uakK8ql06xDC6vK9a31Jhz8zAlu5xoQY8UYj5mvDSMHxJiI07K yXos52OLdGfAc/qyEx4knL+N+UvmJR1bsxzP/aiBzK1ZBbH5bYueM3XhK6kvwxfIO/vQ K3wX6hUraZCB7mGZCa270i+UI0TnH452ZDx+O3D9dY/yqE8bLBFFNI2RpmewxeTqqWk9 6yOSfzG5NIhiRBVeSMZt4tjAdf7cPD9/iIqTAgipJE3tVvfcq2/NuvBdujyyRc80ha1L 5dvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KTXpOKSzMIwkf9Xc/62ZswKipaYYrqY887dNNARFRIM=; b=cA1LglUbFDLd9XPVX6ZFAzAUDwFpogTFmRTjg+wXECZQJoUL+sclbI8Os0A28v9sb4 WD3dDlMRx4xeDdRO6gjaCm8XWDyGDV9gLducYhKdGOXc2VGJng0vmKe0gjHFagOfSpHs HV4Wdg4/93fNq2uc1BVy3sULyqFP2Ri3j6dJqHMa7bTiYNX+UdMfnIy7SgqgpQ28G16X 7Za4wpdFJuGvauO+7mE9bAF7zh3ZDP9d/6s6FqRtHJbI3l3TYWWtMWfcz795l8Lzvxcv YItOT9wYHPXKqwaIr2Wunav9O7CrcaGoTdIHR4zB+i7hCLFbVazYwJ0Oz0bQFz4UyiUz /yfg==
X-Gm-Message-State: AFeK/H0Zi2o11Zl3qaifwIoCcRzYw+0WUUiQOje3JSSYWjTM5NRYQbY4psN8/cxeRMkxbXZ4om20TMpuaR+kpw==
X-Received: by 10.107.16.217 with SMTP id 86mr26099682ioq.228.1490018689892; Mon, 20 Mar 2017 07:04:49 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.35.207 with HTTP; Mon, 20 Mar 2017 07:04:48 -0700 (PDT)
Received: by 10.79.35.207 with HTTP; Mon, 20 Mar 2017 07:04:48 -0700 (PDT)
In-Reply-To: <BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0@BLUPR0501MB2051.namprd05.prod.outlook.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> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> <BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0@BLUPR0501MB2051.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 20 Mar 2017 15:04:48 +0100
X-Google-Sender-Auth: mo2ZSTEoGX0UDPwMcvDDh3hfyME
Message-ID: <CA+b+ER=6BEgTWe0E286GwJzh-q2PD1Uw=qSSC4H22FSgqF=yLw@mail.gmail.com>
To: Ronald Bonica <rbonica@juniper.net>
Cc: "EXT - luis.tomotaki@verizon.com" <luis.tomotaki@verizon.com>, Susan Hares <shares@ndzh.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-sla-exchange.all@ietf.org" <draft-ietf-idr-sla-exchange.all@ietf.org>, Shitanshu Shah <shitanshu_shah@hotmail.com>
Content-Type: multipart/alternative; boundary=001a113ecee8b87c7f054b2a02df
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BRJ21RbzCvpYgn7V31SWf9fuUqE>
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 20 Mar 2017 14:05:00 -0000

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" <rbonica@juniper.net> wrote:

> 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' <shares@ndzh.com>om>; EXT - luis.tomotaki@verizon.com <
> luis.tomotaki@verizon.com>gt;; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>om>;
> rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
> *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:shares@ndzh.com <shares@ndzh.com>]
> *Sent:* Wednesday, March 8, 2017 10:23 AM
> *To:* EXT - luis.tomotaki@verizon.com <luis.tomotaki@verizon.com>om>;
> 'Shitanshu Shah' <shitanshu_shah@hotmail.com>om>; Ron Bonica <
> rbonica@juniper.net>gt;; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.
> all@ietf.org; idr@ietf.org
> *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:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Tomotaki, Luis M
> *Sent:* Tuesday, March 7, 2017 11:11 PM
> *To:* Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org;
> draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
> *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:shitanshu_shah@hotmail.com
> <shitanshu_shah@hotmail.com>]
> *Sent:* Monday, March 6, 2017 9:31 AM
> *To:* Susan Hares <shares@ndzh.com>om>; 'Ron Bonica' <rbonica@juniper.net>et>;
> rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
> *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.
>
>
>
> Regards,
>
> Shitanshu
>
>
> ------------------------------
>
> *From:* Susan Hares <shares@ndzh.com>
> *Sent:* Saturday, March 4, 2017 8:31 AM
> *To:* 'Ron Bonica'; 'Shitanshu Shah'; 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
>
>
>
> 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
> <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; draft-ietf-idr-sla-exchange.
> all@ietf.org; 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.
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>