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

[Nick Hilliard <[e-mail]>]

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.

Nick