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

[Job Snijders <[e-mail]>]

On Mon, 3 Jul 2017 at 22:07, Randy Bush <[e-mail]> wrote:

> > Ah, yes of course WG consensus is important. I had assumed that the
> > authors were expressing their 100% agreement with all my points through
> > silence. ;-)
>
> actually, you atacked the style and tone of my response, so i gave up.



I'm not sure I know what you are referring to. I sent feedback on the draft
to the list (in a fresh thread) and only received a response from Robert
Raszuk. If I discouraged dialogue on this topic in some way, please point
me to it and allow me an opportunity to apologize for doing so.


we have long experience (can you say DataKit?) with bad failures and hard
> debugging of partial data plane connectivity interacting with lack of
> knowledge of the control plane.



Yes. But a route server will never be a full replacement for regular
bilateral sessions, so that will always remain. If the implication is that
the technology (full state available to the RS) is critical in the
maintenance and operation of the IXP itself, it should clearly state so.
This would be new information to me though.

As a generalized mechanism, IXPs could snoop BFD traffic to disseminate the
current state of reachability on the fabric, such BFD snooping would work
for both RS peers as well as bilateral peers. A question would be "why
impose additional reporting duties (load) on the RS peers when the IXP can
glean similar information through snooping"?


when my router's packets can not reach you, or vice versa, i *really* want
> to learn a better place to send them.



Yes. But how does statement show that the route server itself must be kept
appraised on who can reach who?

Kind regards,

Job

>