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 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68B4612D098; Wed, 1 Jun 2016 03:51:06 -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 B3ueIJjvdKn8; Wed, 1 Jun 2016 03:51:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1028512B027; Wed, 1 Jun 2016 03:51:04 -0700 (PDT)
Received: by (Postfix, from userid 33) id 570F574401; Wed, 1 Jun 2016 12:51:02 +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 12:51:02 +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 10:51:06 -0000

On 2016-05-31 17:40, Nick Hilliard wrote:
> Marco Marzetti wrote:
>> Beside i agree on the most part of this draft i would like to 
>> underline
>> how bullet 2.2.2 breaks the the nature of BGP itself.
>> The exact part i am referring to is:
>> """
>>  As a route server does not participate in the process of forwarding
>>    data between client routers, and because modification of the 
>>    attribute could affect route server client BGP Decision Process, 
>> the
>>    route server SHOULD NOT prepend its own AS number to the AS_PATH
>>    segment nor modify the AS_PATH segment in any other way.
>> """
>> I firmly think that it really has to state "MUST NOT" instead of 
>> NOT".
>> From a route-server client point of view that breaks the natural BGP
>> best selection process and forces you to purely rely on 
>> which in turns breaks your traffic engineering because it forces you 
>> to
>> prefer/not-prefer the prefixes learned over the route server in place 
>> of
>> those learned, for instance, over a private session or another IXP.
> It doesn't "break" the decision process mechanism.  Localpref might be
> ugly, but using it doesn't violate the bgp protocol.
> This statement needs to be "MUST NOT".  Technically you can run a route
> server even if you insert the intermediate ASN into the path.  The only
> absolute "MUST" is that you mustn't change the next-hop; otherwise you
> end up with a router instead of a route server.
> RFC2119 is a pain because there is no way of differentiating between
> "SHOULD NOT", meaning "on balance it would be a better idea not to do 
> X"
> and "SHOULD NOT", meaning "if you even _think_ about doing X, you need
> your head examined and the only reason we specified SHOULD NOT instead
> of MUST NOT in this situation because of some technicality that
> prevented us from doing so".  The text in 2.2.2 veers slightly in the
> direction of the latter interpretation.
> Nick


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.