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

[Jeffrey Haas <[e-mail]>]

On Tue, Jul 04, 2017 at 11:26:46AM +0200, Job Snijders wrote:
> I posit that it is safe to assume that other (non-RS) paths will always
> exist (via transit, other peering), and as such in the trade-off between
> keeping more state at the RS vs trying to keep the RS lean and mean, the
> design parameters should be as following:
> 
>     - the main purpose of this draft is to ensure that each RS
>       participant sets up BFD sessions to the other participants of
>       interest, the main purpose is _not_ to ensure there are always
>       paths even if half the IX is on fire. The priority should be quick
>       fault detection, not to "make the best use of the IX under any and
>       all circumstances".
> 
[intentional re-ordering of your text...]
> 
>     - The technology facilitate setting up the minimum required set of
>       BFD sessions, not the maximum.

The draft already accomplishes these.

>     - we should work from the assumption that if a client supports
>       draft-ietf-idr-rs-bfd, it will also have support for ADD-PATH. If
>       we cannot assume this, I'd like to understand why.
> 
>     - explicitly consider scalability issues. The bigger internet
>       exchanges are struggling with their current route server load, so
>       if IDR adds any computational cost to their list of tasks, it'll
>       need to properly justify that.

The draft does not require the RS to support additional path selection.  It
does, however, enable it if the RS is capable of such things.



-- Jeff