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> Fri, 27 May 2016 10:08 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 712A212D646 for <ietf@ietfa.amsl.com>; Fri, 27 May 2016 03:08:21 -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 3tY21pucD3sA for <ietf@ietfa.amsl.com>; Fri, 27 May 2016 03:08:17 -0700 (PDT)
Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBFD12B010 for <ietf@ietf.org>; Fri, 27 May 2016 03:08:11 -0700 (PDT)
Received: by seele.lamehost.it (Postfix, from userid 33) id D759174401; Fri, 27 May 2016 12:08:08 +0200 (CEST)
To: Greg Skinner <gregskinner0@icloud.com>
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 <marco@lamehost.it>
In-Reply-To: <EC1DA45D-52AF-4CAB-9938-55B04B25091F@icloud.com>
References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <3a393cca96dd9da1880c7ce85796a297@lamehost.it> <EC1DA45D-52AF-4CAB-9938-55B04B25091F@icloud.com>
Message-ID: <d7126aa7ba422565374c613a5a97182d@lamehost.it>
X-Sender: marco@lamehost.it
User-Agent: Roundcube Webmail/1.1.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/CW47XbLYUoKIS1suTMhx5bUmTUk>
Cc: ietf@ietf.org
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: 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 <marco@lamehost.it> >> 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 >>> 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 > 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] http://peeringforum.bknix.co.th/2016/docs/Bob%20Lau%20(Akamai).pdf 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 practice. 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. Regards -- Marco
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Greg Skinner
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Nick Hilliard
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Nick Hilliard
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… David Huberman
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Robert Raszuk
- Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route… Marco Marzetti