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

[Job Snijders <[e-mail]>]

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

> On Jul 3, 2017, at 5:31 PM, Job Snijders <[e-mail]> wrote:
>
>
> 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.
>
>
> Yes, but I think the part you are overlooking is that the RS asks the
> client to track connectivity to all candidate next-hops, whether or not the
> RS is currently sending the client a route with that next hop.
>

Conceptually there isn't a big difference between exchanging this
information in bulk or as deltas. But thank you for pointing this out, I
now also wonder whether it is efficient for a RS participant to track
next-hops it migh not have any business with. That seems like a waste of
resources.


So #1 can only happen if rs-bfd is implemented,
>
>
> Yes, but.
>
> and the cadence would be a logical consequence if add-path is not
> supported.
>
>
> That's the error. Numbers 2 and 3 wouldn't happen if rs-bfd were
> implemented as written, because in step zero the RS would have said "hey
> client, please use BFD towards A and B" and in step 1, the client would say
> "hey RS, can't reach A, also can't reach B".
>


I'm not sure whether events will be packed together this neatly.

Questions that remain:

- is it absolutely necessary for the RS to be aware of the entire bfd
session topology state?

- is it reasonable to assume there will be BGP speakers that support
draft-ietf-idr-rs-bfd, but not RFC 7911?

- if the RS is not stateless (in this regard), can we reasonable expect
things to scale? (As it currently stands the industry has trouble scaling
RS services)

If it was not clear from previous messages: I am supportive of the idea of
"assisted BFD" to take away some obvious downsides of route servers. Just
not sure the proposed approach will work out good enough.

Kind regards,

Job

>