Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

"Osborne, Eric" <eric.osborne@level3.com> Thu, 09 June 2016 17:27 UTC

Return-Path: <eric.osborne@level3.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 55FF612B03F; Thu, 9 Jun 2016 10:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JL109Px0Usy6; Thu, 9 Jun 2016 10:27:56 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A68512D188; Thu, 9 Jun 2016 10:27:56 -0700 (PDT)
Received: from [216.82.241.195] by server-7.bemta-8.messagelabs.com id 79/96-14830-B17A9575; Thu, 09 Jun 2016 17:27:55 +0000
X-Env-Sender: eric.osborne@level3.com
X-Msg-Ref: server-16.tower-119.messagelabs.com!1465493274!42814851!1
X-Originating-IP: [209.245.18.37]
X-StarScan-Received:
X-StarScan-Version: 8.46; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18560 invoked from network); 9 Jun 2016 17:27:54 -0000
Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-16.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jun 2016 17:27:54 -0000
Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 4337E1DEBE; Thu, 9 Jun 2016 17:27:54 +0000 (GMT)
Received: from USIDCWVEQCCAS04.corp.global.level3.com (4.72.133.44) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.279.2; Thu, 9 Jun 2016 11:27:54 -0600
Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEQCCAS04.corp.global.level3.com ([4.72.133.44]) with mapi id 14.03.0279.002; Thu, 9 Jun 2016 11:27:53 -0600
From: "Osborne, Eric" <eric.osborne@level3.com>
To: Alexander Azimov <aa@qrator.net>, Job Snijders <job@instituut.net>
Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
Thread-Index: AQHRwmyTIh9xLxm6hkqQUlM8iRp1op/hxNeA//+eFHA=
Date: Thu, 09 Jun 2016 17:27:52 +0000
Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772@USIDCWVEMBX03.corp.global.level3.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> <CAHgCvCOMXZKH80YLm=PCv6_PPu3Gp8J6ZR+ed+P_eh953CMt3w@mail.gmail.com>
In-Reply-To: <CAHgCvCOMXZKH80YLm=PCv6_PPu3Gp8J6ZR+ed+P_eh953CMt3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.196.206]
Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772USIDCWVEMBX03co_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PdkubiRFohI7MaP3zIty1I6X3w0>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation@ietf.org>, Susan Hares <shares@ndzh.com>, "John G. Scudder" <jgs@bgp.nu>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
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: Thu, 09 Jun 2016 17:27:59 -0000

I don’t like #2.  It doesn’t make sense to me – a single neighbor may have some customer aspects and some peer aspects, and splitting a single BGP session into two is conceptually weird and also a huge code uplift on both ends.

#1 makes sense and is along the lines of what I was hinting at in my ‘support’ – don’t just give me pass/fail, give me flexible knobs in an implementation.  I realize that doing this per-prefix is anothet way to do it, but see my other email to Sriram for why I don’t like path state much.

I suppose I could see non-transitive per-prefix as another way to do this; if it was that vs open message, there are good arguments either way.




eric

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alexander Azimov
Sent: Thursday, June 09, 2016 1:16 PM
To: Job Snijders <job@instituut.net>
Cc: idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org; John G. Scudder <jgs@bgp.nu>; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Dear Job,

Thank you for joining discussion!

I can't imagine situation when there would be changes in roles between two neighbors on regular basis. So, we should not suffer from lots of BGP flaps caused by roles.

In second point you've highlighted most common concern about different prefix-based route policies in same BGP session. There are at least two workarounds:

  1.  Add 'custom' role and give in such sessions access to manual OTC configuration (there would be new appropriate pair of roles custom-custom)
  2.  Split such BGP sessions into two with different roles
For myself I do prefer second option - I would like to see route leak mitigation as built in and fully automated mechanism, with no opportunity for 'fat fingers' get inside. This could bring additional work for NOC teams in short term, but in long term benefit from controlling neighbor configuration (especially in case of new ISPs) will fully cover the spent time. But what do you think according to your operational experience?


2016-06-09 19:32 GMT+03:00 Job Snijders <job@instituut.net<mailto:job@instituut.net>>:
Dear Authors, IDR group,

I'd like to start by thanking you for putting thought and time into the
route leak problem space. It is encouring to see fellow operators engage
with the IETF community to address actual, day to day issues.

On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote:
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy.
> You can find the draft at:
>
> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.
>
> In your comments on adopting this draft, please indicate:
>
> 1)      "Support" or "no Support"

No support.

> 2)      Do you feel this is a way to prevent route leaks?

It certainly is a way.

> 3)      Are there any deployment issues that might prevent deployment
> of this enhancement to BGP Open?

I do not think that the OPEN moment in the lifecycle of a BGP session is
the appropiate place for policy constructs like this. In practise it is
probably not an issue when you have to flap a BGP session to change the
relation between two ASNs, but it would be nice if this is not required
(like today on most platforms).

Secondly (and more importantly), the roles are not necessarily a BGP
session-specific characteristic, but rather a prefix-specific property.
The proposed OPEN method does not provide for this level granularity if
I am reading it correctly. The method would affect all prefixes exchange
over a BGP session, without exception.

> 4) Does this interact with
> draft-ietf-idr-route-leak-detection-mitigation?

Yes, in terms of the problem being addressed.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr



--
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: aa@qrator.net<mailto:aa@qrator.net>
| visit: www.qrator.net<http://www.qrator.net/>