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, 01 June 2016 10:51 UTC
Return-Path: <marco@lamehost.it>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B4612D098; Wed, 1 Jun 2016 03:51:06 -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 B3ueIJjvdKn8; Wed, 1 Jun 2016 03:51:04 -0700 (PDT)
Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1028512B027; Wed, 1 Jun 2016 03:51:04 -0700 (PDT)
Received: by seele.lamehost.it (Postfix, from userid 33) id 570F574401; Wed, 1 Jun 2016 12:51:02 +0200 (CEST)
To: Nick Hilliard <nick@foobar.org>
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, 01 Jun 2016 12:51:02 +0200
From: Marco Marzetti <marco@lamehost.it>
In-Reply-To: <574DB060.1000801@foobar.org>
References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org>
Message-ID: <c27a95712dc581e393a7cdfc1c12d207@lamehost.it>
X-Sender: marco@lamehost.it
User-Agent: Roundcube Webmail/1.1.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/y4p5F6rV2xqN626_KQBuJVpLW_I>
Cc: Idr@ietf.org, 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-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 10:51:06 -0000
On 2016-05-31 17:40, Nick Hilliard wrote: > Marco Marzetti wrote: >> 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. > > It doesn't "break" the decision process mechanism. Localpref might be > ugly, but using it doesn't violate the bgp protocol. > > This statement needs to be "MUST NOT". Technically you can run a route > server even if you insert the intermediate ASN into the path. The only > absolute "MUST" is that you mustn't change the next-hop; otherwise you > end up with a router instead of a route server. > > RFC2119 is a pain because there is no way of differentiating between > "SHOULD NOT", meaning "on balance it would be a better idea not to do > X" > and "SHOULD NOT", meaning "if you even _think_ about doing X, you need > your head examined and the only reason we specified SHOULD NOT instead > of MUST NOT in this situation because of some technicality that > prevented us from doing so". The text in 2.2.2 veers slightly in the > direction of the latter interpretation. > > Nick Nick, 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. Regards -- Marco
- [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-ser… The IESG
- 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