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

[joel jaeggli <[e-mail]>]

On 6/14/16 9:09 AM, Nick Hilliard wrote:
> 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.

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.

>> 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
>