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

Marco Marzetti <> Fri, 27 May 2016 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 712A212D646 for <>; Fri, 27 May 2016 03:08:21 -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 3tY21pucD3sA for <>; Fri, 27 May 2016 03:08:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1FBFD12B010 for <>; Fri, 27 May 2016 03:08:11 -0700 (PDT)
Received: by (Postfix, from userid 33) id D759174401; Fri, 27 May 2016 12:08:08 +0200 (CEST)
To: Greg Skinner <>
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="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Fri, 27 May 2016 12:08:08 +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: Fri, 27 May 2016 10:08:21 -0000

On 2016-05-27 08:59, Greg Skinner wrote:
>> 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
>> 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
>> 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
>  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 [1].  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
> draft-ietf-idr-add-paths-13.
> —gregbo
> Links:
> ------
> [1]

Dear Greg,

I have had private chats with Niels and Nick before i submitted my rant 
and i understand their reasons, but i really don't agree with them.
In fact I think that the community should firmly discourage that 

About draft-ietf-grow-ix-bgp-route-server-operations: this is the 
relevant excerpt:
    As [I-D.ietf-idr-ix-bgp-route-server] suggests that route servers
    should not modify the AS_PATH attribute, a consistency check on the
    AS_PATH of an BGP route received by a route server client would
    normally fail.  It is therefore RECOMMENDED that route server clients
    disable the AS_PATH consistency check towards the route server.

The words "RECOMMEND" and "SHOULD" imply that there could be a valid 
reason, but i can't find any.
Now, we may address that in this draft only, but it would lack common 
sense because the theory would let room to a practice that is denied in 
the operations.