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

Greg Skinner <> Fri, 27 May 2016 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3084412B071 for <>; Fri, 27 May 2016 00:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PCWXn34f5qzf for <>; Fri, 27 May 2016 00:00:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2268212B05E for <>; Fri, 27 May 2016 00:00:03 -0700 (PDT)
Received: (qmail 14884 invoked by uid 17031); 27 May 2016 07:00:00 -0000
Received: from unknown (HELO []) (gds@[]) (envelope-sender <>) by (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <>; 27 May 2016 07:00:00 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_638227EA-7458-4554-AA88-8B9D699C5F78"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard
From: Greg Skinner <>
In-Reply-To: <>
Date: Thu, 26 May 2016 23:59:57 -0700
Message-Id: <>
References: <> <>
To: Marco Marzetti <>
X-Mailer: Apple Mail (2.3124)
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: Fri, 27 May 2016 07:00:05 -0000

> On May 25, 2016, at 6:11 AM, Marco Marzetti <> wrote:
> On 2016-05-25 00:43, The IESG wrote:
>> The IESG has received a request from the Inter-Domain Routing WG (idr) to
>> consider the following document:
>> - 'Internet Exchange BGP Route Server'
>>  <draft-ietf-idr-ix-bgp-route-server-10.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> mailing lists by 2016-06-07. Exceptionally, comments may be
>> sent to instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> Abstract
>>   This document outlines a specification for multilateral
>>   interconnections at Internet exchange points (IXPs).  Multilateral
>>   interconnection is a method of exchanging routing information between
>>   three or more external BGP speakers using a single intermediate
>>   broker system, referred to as a route server.  Route servers are
>>   typically used on shared access media networks, such as Internet
>>   exchange points (IXPs), to facilitate simplified interconnection
>>   between multiple Internet routers.
>> The file can be obtained via
>> IESG discussion can be tracked via
>> No IPR declarations have been submitted directly on this I-D.
>> _______________________________________________
>> Idr mailing list
> All,
> 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 AS_PATH
>   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 "SHOULD NOT".
> From a route-server client point of view that breaks the natural BGP best selection process and forces you to purely rely on LOCAL_PREFERENCE 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.
> Regards
> -- 
> Marco

There are some IXP route servers that prepend their AS number to the AS_PATH, according to some things I’ve read, such as this Akamai presentation <>.  My guess is the use of “SHOULD NOT” here reflects that this is not a recommended procedure.

Since your concerns about traffic engineering are operational in nature, perhaps you could address them via draft-ietf-grow-ix-bgp-route-server-operations.

Incidentally, idnits turned up an outdated reference: a later version (-15) exists of