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

Nick Hilliard <nick@foobar.org> Tue, 31 May 2016 15:40 UTC

Return-Path: <nick@foobar.org>
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 CC05512D1E8; Tue, 31 May 2016 08:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nYN6h_AOLsdc; Tue, 31 May 2016 08:40:21 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0BC12D5D7; Tue, 31 May 2016 08:40:20 -0700 (PDT)
X-Envelope-To: Idr@ietf.org
Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u4VFeHjD087010 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2016 16:40:17 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local
Message-ID: <574DB060.1000801@foobar.org>
Date: Tue, 31 May 2016 16:40:16 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Marco Marzetti <marco@lamehost.it>
Subject: Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard
References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it>
In-Reply-To: <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/9QkaLUo0oNaA6a8EmgpY9XInbao>
Cc: Idr@ietf.org, 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: Tue, 31 May 2016 15:40:29 -0000

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