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

Marco Marzetti <marco@lamehost.it> Wed, 25 May 2016 13:14 UTC

Return-Path: <marco@lamehost.it>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E4C12DC52 for <ietf@ietfa.amsl.com>; Wed, 25 May 2016 06:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alXeKSCA8BAN for <ietf@ietfa.amsl.com>; Wed, 25 May 2016 06:14:33 -0700 (PDT)
Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 614D612DA1A for <ietf@ietf.org>; Wed, 25 May 2016 06:11:57 -0700 (PDT)
Received: by seele.lamehost.it (Postfix, from userid 33) id 1BE7C74401; Wed, 25 May 2016 15:11:56 +0200 (CEST)
To: ietf@ietf.org
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, 25 May 2016 15:11:55 +0200
From: Marco Marzetti <marco@lamehost.it>
In-Reply-To: <20160524224341.14017.96672.idtracker@ietfa.amsl.com>
References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com>
Message-ID: <3a393cca96dd9da1880c7ce85796a297@lamehost.it>
X-Sender: marco@lamehost.it
User-Agent: Roundcube Webmail/1.1.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/hSrFf8Pg6rCZj-yilaztfiyu6uw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2016 13:14:37 -0000

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
> ietf@ietf.org mailing lists by 2016-06-07. Exceptionally, comments may 
> be
> sent to iesg@ietf.org 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
> https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

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