IETF Logo Mail Archive

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

"Osborne, Eric" <eric.osborne@level3.com> Mon, 06 June 2016 17:00 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 DA43A12D150; Mon, 6 Jun 2016 10:00:46 -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 j9GeH8FZQ23u; Mon, 6 Jun 2016 10:00:45 -0700 (PDT)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) (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 66A1912D1AA; Mon, 6 Jun 2016 10:00:45 -0700 (PDT)
Received: from [216.82.250.99] by server-3.bemta-12.messagelabs.com id F1/DB-21945-C3CA5575; Mon, 06 Jun 2016 17:00:44 +0000
X-Env-Sender: eric.osborne@level3.com
X-Msg-Ref: server-10.tower-126.messagelabs.com!1465232444!52932893!1
X-Originating-IP: [209.245.18.38]
X-StarScan-Received:
X-StarScan-Version: 8.46; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8507 invoked from network); 6 Jun 2016 17:00:44 -0000
Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-10.tower-126.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jun 2016 17:00:44 -0000
Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id DE0222DA47; Mon, 6 Jun 2016 17:00:43 +0000 (GMT)
Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEHT01.corp.global.level3.com ([::1]) with mapi id 14.03.0279.002; Mon, 6 Jun 2016 11:00:43 -0600
From: "Osborne, Eric" <eric.osborne@level3.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQAAqhng
Date: Mon, 06 Jun 2016 17:00:43 +0000
Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com>
In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.196.205]
Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5EUSIDCWVEMBX03co_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/af_r_TNYqGvK5GtoJ_Ew-HeYRBo>
Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation@ietf.org>, "'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: Mon, 06 Jun 2016 17:00:47 -0000

1)      I support solving the problem this draft set out, and this draft seems to be a good start at wrestling with the problem.

2)      This works better on a white board than in real life.  In particular, terms like Peer and Customer and Transit have commercial connotations as well as technical ones.  It may be that some operators have a Providers (fiscal relationship) but with which they exchange routes as if it were a Peer.  Or Customer/Peer, or Customer/Provider.  I am a little concerned about translating the strict rules in this doc into a more nuanced BGP policy which reflects business policy.  I encourage anyone who implements this to not just make it a "Role must match or I'm going to tear the neighbor down" sort of thing.

3)      See #2

4)      I just briefly skimmed detection-mitigation, and that seems like a much more heavyweight way to implmement the same sort of end behavior.




eric


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, June 06, 2016 12:40 PM
To: idr@ietf.org
Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudder' <jgs@bgp.nu>
Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

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"

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

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

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

Sue Hares and John Scudder

v2.23.0 | Report a Bug | By Email