Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

Nick Hilliard <> Tue, 14 June 2016 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9657512D7D3; Tue, 14 Jun 2016 09:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UA5jnwhwikXC; Tue, 14 Jun 2016 09:09:19 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F98612B013; Tue, 14 Jun 2016 09:09:19 -0700 (PDT)
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u5EG9CNb006286 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 17:09:13 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
Message-ID: <>
Date: Tue, 14 Jun 2016 17:09:11 +0100
From: Nick Hilliard <>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Joel Jaeggli <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,, The IESG <>,,
Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jun 2016 16:09:22 -0000

Joel Jaeggli wrote:
> I'm at a bit of a loss to understand why path hiding would be a
> considered an undesirable property of an MLPE routeserver.

Because in certain circumstances, if you have two paths A and B to a
leaf node L, and path A decides to block access to L via the IXP, A's
policy action acting on the RS will also block path B.  There are no
circumstances that I can imagine where this would be a desirable outcome.

> IMHO as an
> operator that peers on MLPE exchanges as well as bilaterally on exchange
> fabrics and via PNIs. blinding a client of the MLPE which I  may have a
> session already with at the exchange or via PNI is basically mandatory.

We're talking about different things here.  Blinding a path by offering
a better alternative is fine - which is, I think, what you are talking
about.  Blinding a path by denying third parties a failover path is not ok.

> Likewise without per-asn export policy at exchanges my ability to
> advertise anycast prefixes via the MLPE is basically noexistant
>    If an IXP operator deploys a route server without
>    implementing a per-client routing policy control system, then path
>    hiding does not occur as all paths are considered equally valid from
>    the point of view of the route server.
> Does not seem like a particularly desirable outcome.
> While I'm fine with 2.3 not being normative, it does seem desirable that
> an MLPE service offer the client control, it greatly increases the sorts
> of clients that can safely use the service.

Yep, agreed.  This was an issue that Geoff Huston brought up during the
rtgdir review.  His point was that a standards track document cannot
recommend a course of action which is not formally defined anywhere.  At
the moment, neither add-path nor the multiple rib options have been
defined formally within standards track documents.  So as authors we had
an option of either delaying publication of this draft for an
indeterminate number of years while the multi-rib and add-path drafts
were standardized, or else mark these as non-normative for the time
being and standardise the rest of the requirements.

Given that ietf-idr-add-paths has been in the ietf process since 2002
and it's now 2016, we figured it was probably a more practical solution
to move ahead with this draft as-is, and if someone wants to document
multiple ribs in future, this draft can be updated.