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

Marco Marzetti <> Wed, 01 June 2016 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7AD112D190; Wed, 1 Jun 2016 05:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NR7C5oVBBack; Wed, 1 Jun 2016 05:12:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6721D12D18F; Wed, 1 Jun 2016 05:12:24 -0700 (PDT)
Received: by (Postfix, from userid 33) id C5EFD74401; Wed, 1 Jun 2016 14:12:23 +0200 (CEST)
To: Nick Hilliard <>
Subject: Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard
X-PHP-Originating-Script: 0:rcube.php
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 01 Jun 2016 14:12:23 +0200
From: Marco Marzetti <>
In-Reply-To: <>
References: <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.1.5
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2016 12:12:28 -0000

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


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.