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

Randy Bush <> Sat, 11 June 2016 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01C9412D903 for <>; Fri, 10 Jun 2016 21:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5TdKg8pBe6Dr for <>; Fri, 10 Jun 2016 21:56:26 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECF6812D917 for <>; Fri, 10 Jun 2016 21:56:25 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.82) (envelope-from <>) id 1bBay8-0001Ir-Ad; Sat, 11 Jun 2016 04:56:24 +0000
Date: Fri, 10 Jun 2016 21:56:23 -0700
Message-ID: <>
From: Randy Bush <>
To: Robert Raszuk <>
In-Reply-To: <>
References: <012e01d1c012$1d05f8d0$5711ea70$> <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Cc: idr wg <>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Jun 2016 04:56:27 -0000

> However my honest observation is that this approach would work well
> when operators would only operate on binary BGP code with such
> functionality enabled as mandatory capability and be always ON by
> default with no option to disable it.  Said this we all have to admit
> that such times are long gone and as soon as NOC have a business case
> and chance to disable it their marketing folks will force them to do
> so.
> So the real question comes to the point if IDR is in position to issue
> RFCs to test ISP marketing guys in their level of power to enforce big
> vendors to add knobs disabling such capabilities or speeding up
> shifting to open source BGP ....

complex twisty path which starts and ends in unhelpful places.

i am not interested in a vendor nanny state, never have been.  see the
very careful and complete operator control in RFC 6811 BGP Prefix Origin

if i know i have a 'normal' relationship with a bgp neighbor, give me to
tools to mark it as such and to detect and maybe even ameliorate damage
by [untentional (i am an optimist)] violation of that normality.

if i do not have a normal relationship, i won't use protective tools
which assume and enforce normality.

life can be simple.