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

["Joel Jaeggli" <[e-mail]>]

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.