Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

[Job Snijders <[e-mail]>]

On Mon, Jul 03, 2017 at 07:38:10PM +0200, Gert Doering wrote:
> On Mon, Jul 03, 2017 at 06:38:46PM +0200, Job Snijders wrote:
> > I look forward to hearing counterpoints as to why it is useful to
> > communicate reachability state back to the route server, and how the
> > authors (or other working group participants) envision the scalability
> > cost aspect.
> 
> I find this a useful point for telemetry so the IXP operator can know
> "there is loss of connectivity between participant".

Sure, but there is a cost associated with the distribution of this
information. Additionally, IXP operators seem to be able to also
retrieve this information in other ways: real time analysis of
{net,s}flow data, deploying their own site-to-site monitoring (example:
https://ams-ix.net/technical/statistics/real-time-stats) 

I'd argue that "it is may be interesting to know this" is a weaker
argument then "without this knowledge the technology doesnt work". As it
currently stands, all route server implementations are struggling with
high volume, so adding additional load doesn't seem attractive. "Just
because we can" doesn't go well with a resource constrained construct
like a route server.

> Also, it enables best-path selection on the route-server to pick other
> paths if available.

This is addressed through ADD-PATH / RFC 7911. By the time
draft-ietf-idr-rs-bfd gets anywhere I expect that ADD-PATH is
implemented on all common platforms. It would seem unlikely to me that
we'll have BGP implementations that implement draft-ietf-idr-rs-bfd but
not RFC 7911.

Kind regards,

Job