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

[Job Snijders <[e-mail]>]

On Mon, 3 Jul 2017 at 23:18, John G. Scudder <[e-mail]> wrote:

On Jul 3, 2017, at 5:10 PM, Job Snijders <[e-mail]> wrote:
> On Mon, 3 Jul 2017 at 22:53, Randy Bush <[e-mail]> wrote:
>
>> > I don't follow. If the route server facilitates you in setting up BFD to
>> > all "nexthops of interest", the route server's job is done, right? Any
>> RS
>> > peer has the ability to locally verify reacahbility across the fabric
>> and
>> > route accordingly.
>>
>> route servers are for the small folk who can not do full mesh, let alone
>> add path and other fancy things.  the rs IS their control plane, period.
>>
>
> If a device can't do add-path, can we really expect these devices to do
> fancy things like opportunistic "route server assisted" BFD to all
> next-hops of interest?
>
> If we operate under the assumption that these clients can't support
> receiving multiple paths through add-path, I envision a somewhat ugly
> cadence:
>
> 1) Hey RS, can't reach A
> 2) Ok, here try reaching A via B
> 3) hey RS, I can't reach B either
> Etc, etc
>
>
> If that cadence happens, they haven't implemented what's in rs-bfd, right?
> So why would even #1 happen?
>


Perhaps my understanding of the draft is flawed,  but rs-bfd (currently)
specifies the concept of relaying information from RS participant back to
the RS about who the participant can reach or not. So #1 can only happen if
rs-bfd is implemented, and the cadence would be a logical consequence if
add-path is not supported.

Kind regards,

Job

>