Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard

David Huberman <david.huberman@oracle.com> Wed, 01 June 2016 12:21 UTC

Return-Path: <david.huberman@oracle.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0412D18F; Wed, 1 Jun 2016 05:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 2bNsd0WAbizh; Wed, 1 Jun 2016 05:21:22 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 3C23112D184; Wed, 1 Jun 2016 05:21:22 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u51CLCZj014839 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 12:21:12 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u51CLBZO029275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 12:21:11 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u51CL8wr015603; Wed, 1 Jun 2016 12:21:10 GMT
Received: from [21.9.110.26] (/172.56.35.57) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jun 2016 05:21:08 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard
From: David Huberman <david.huberman@oracle.com>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <b89e12cebdffc1324f797b82db1a3ad1@lamehost.it>
Date: Wed, 01 Jun 2016 07:21:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE1E1757-C6EF-49B0-B9F0-5B07607BF123@oracle.com>
References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> <c27a95712dc581e393a7cdfc1c12d207@lamehost.it> <574EC42C.3040500@foobar.org> <b89e12cebdffc1324f797b82db1a3ad1@lamehost.it>
To: Marco Marzetti <marco@lamehost.it>
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5T4ozsBACZJwYe_b1L-r9NgbcY8>
Cc: Idr@ietf.org, ietf@ietf.org, Nick Hilliard <nick@foobar.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 12:21:24 -0000

Pardon the top post. 

Marco, we do these things in the real world generally because we have to, not because we don't know any better. IX participants come in all kinds of flavors, and some have to turn some really weird BGP knobs to ensure everything works.  

I very much appreciate your position -- clean, optimal standards are a great goal -- but real world operability is the true MUST HAVE of a standard.

David

> On Jun 1, 2016, at 7:12 AM, Marco Marzetti <marco@lamehost.it> wrote:
> 
>> On 2016-06-01 13:17, Nick Hilliard wrote:
>> Marco Marzetti wrote:
>>> I agree with you that you can run a route server and insert your ASn in
>>> the path, but i think that is a lack of common sense which brings only
>>> contraries and no benefits.
>>> About RFC2119: It says that "SHOULD NOT" implies a valid reason to
>>> accept a behavior, but i can't find any.
>> I agree that it is not a clever thing to do. The valid reason to accept
>> the behaviour is that it works in practice: some IXPs have done this in
>> production, in many cases for years.
>> There is a secondary reason: some rs client bgp stacks don't support the
>> option to accept an AS path from the RS where the leftmost entry on the
>> AS path != peeras.
>> These are not "good" reasons in the sense that they mandate behaviour
>> which is suboptimal, but they are valid reasons.
>> Nick
> 
> Nick,
> 
> I think that we should define a standard that addresses and corrects those non-clever behaviors rather than embrace them.
> 
> My point is: even if they work in the real world, they do because of the workarounds that other people put in place and they bring no benefits.
> 
> Regards
> 
> -- 
> Marco
>