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

From: "Joel Jaeggli" <[email-masked]>
Date: Tue, 14 Jun 2016 08:37:54 -0700

Joel Jaeggli has entered the following ballot position for
draft-ietf-idr-ix-bgp-route-server-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm at a bit of a loss to understand why path hiding would be a
considered an undesirable property of an MLPE routeserver.  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.
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.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2016 17:09:11 +0100

Joel Jaeggli wrote:
> 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

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.

> 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

---

From: joel jaeggli <[email-masked]>
Date: Tue, 14 Jun 2016 09:34:09 -0700

> circumstances that I can imagine where this would be a desirable outcome.

IF L is a customer of A and B sure. If it's L's policy that's doing the
blocking and you're not winning unequivically on as path length due to
prepending then a  desired result, (not transiting the exchange) is
achieved.  (this isn't really hypotethtical as at least one of my
transit providers has been known to leak our anycast prefixes via mlpe
sesssions at an exchange where we are also present) eventually I won't
use them.

For me as a prefix originator,  the difference is the ability to
advertise prefixes on the MLPE and not, e.g. it's effectively unusable
without that property.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2016 17:52:18 +0100

joel jaeggli wrote:
> IF L is a customer of A and B sure.

you mean, if L is a downstream of A and B - not necessarily a customer.

> If it's L's policy that's doing the blocking

This is the point - it's not L's policy that's doing the blocking.  If A
blocks L's prefixes at the RS, it will block all paths, via both A and
B, even though it should have no control over B's paths if it decides to
take itself out of the equation.

Nick

---

From: joel jaeggli <[email-masked]>
Date: Tue, 14 Jun 2016 10:01:08 -0700

> you mean, if L is a downstream of A and B - not necessarily a customer.

if it's a peer we'd view either of them sending it to the exchange as a
leak. The difference between in the downstream cone and customer route
is defintional

> take itself out of the equation.

sure, easy enough to concede.

Albiet I rather prefer to take b out of the equation when it's my prefix.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 15 Jun 2016 14:53:17 +0000

On 6/14/16, 11:09 AM, "iesg on behalf of Nick Hilliard"
<[email-masked] on behalf of [email-masked]> wrote:

Nick:

Hi!

>multiple ribs in future, this draft can be updated.

:-)

FYI..  draft-ietf-idr-add-paths is already in the RFC Editor's queue, so
it'll most likely be published as an RFC before this document.

Alvaro.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Jun 2016 15:54:33 +0100

> it'll most likely be published as an RFC before this document.

Hopefully!

The most widely-used workaround - multiple RIBs - has never been defined
anywhere :-(

Nick