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

Robert Raszuk <> Wed, 01 June 2016 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2893012D1BE; Wed, 1 Jun 2016 05:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3_cT_XxzofhP; Wed, 1 Jun 2016 05:35:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F07112D194; Wed, 1 Jun 2016 05:35:47 -0700 (PDT)
Received: by with SMTP id s64so11871567lfe.0; Wed, 01 Jun 2016 05:35:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ITiN11Fem0OvwowyqX3LJ5CBFvit+9u11+Bg3YarUpE=; b=cx27ORTA2hqNtA7MoBLJvFbhmqx6hUPjsfAfftd9K/dKGtqEH1kfNJDzPYYPnc/Nhj mVgEh2mvLO7AATvINRm2ET21O+zrhS26MUHUJ1DsdLtGpfklMEN1T9l1KNZxzUq6FxnL xGV0DydDTc/tNF1nnKLC6pia14c8wRZwk72/r09bkN3VHL6Mf9WVP1JGlfnHl9/uNf+4 xptpcQnpwgZwtOy4KBtdoCtLQH/xrrciW9G6+/4457hM0IR/j6MOFU7wr6GLrxsA//5c /xknT6DJNj+oX55S08L7/B78CAwe9sHV3PRKe9fsVK4XqYvGEkQjTMMLrrOKMXc90S72 mM8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ITiN11Fem0OvwowyqX3LJ5CBFvit+9u11+Bg3YarUpE=; b=FtechE4JcYlLLvWE+DYPXSXG5WeSdAbN2baiJm2DVL3PfX2fW1hDQqj5XIwsSIer5n WBqBq8x6JT+uOPVkQDTQmqTV6mBexOQQGo1taaIBIGkp5iOcb2mFeg6QfREVPv1svsu1 THaI16JxKMIaG4LP09lTlh2/tT5TCMkyEF6dZnEoqzSs8rWgw8X831OrMWxT1vambMBh 23+/zI7TcPihQKyYc/Air28Y6goxiP8fDCjZgiCrjj2tr1ZYmUsCZ3tPjO2UztJLRkdE GQQZCs/WkCrqNmebWUxIoXIBdKPNDSuXr5o2vTAQ5hLu7YUex2RGWzaf3sc3HZhSiTZV TuKA==
X-Gm-Message-State: ALyK8tI/xebNyQNYIUbQebyBzRB3rqO73/5AVUMAMevGji+CdFyuCkgnkqHRtu7bcSex2cxoIv7Z96hS/TVSrg==
MIME-Version: 1.0
X-Received: by with SMTP id 139mr1522605ljf.9.1464784545708; Wed, 01 Jun 2016 05:35:45 -0700 (PDT)
Received: by with HTTP; Wed, 1 Jun 2016 05:35:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 1 Jun 2016 14:35:45 +0200
X-Google-Sender-Auth: 4awnEiv_Uk8EJBE3RRUCDOZg4TI
Message-ID: <>
Subject: Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard
From: Robert Raszuk <>
To: Marco Marzetti <>
Content-Type: multipart/alternative; boundary=001a114a8a1c84fdef053436baa3
Archived-At: <>
Cc: idr wg <>, IETF Discussion <>, Nick Hilliard <>
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:35:54 -0000

Hi Marco,

Let's also observe that route server we are defining here which effectively
"reflects" between EBGP sessions has much more wider use then Internet
Exchange points.

There is more architectures which use EBGP and for scale full meshing them
is a headache (at least till we progress the auto discovery proposal
further). And some of those ASes may be private hence inserting your AS
during private removal is rather a must.

I would recommend that we focus on the recommendation how to build IX in
the companion draft in GROW. Here in IDR we should rather accommodate all
use cases.

Many thx,

On Wed, Jun 1, 2016 at 2:12 PM, Marco Marzetti <> 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