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

[Robert Raszuk <[e-mail]>]

>
> let's break tradition and actually see what the document says.
>

​Let's also break tradition and become a bit open minded to look at bigger
picture vs just consider on one specific solution to the problem.


> Abstract
>
>    When route servers are used, the data plane is not congruent with the
>    control plane.  Therefore, the peers on the Internet exchange can
>    lose data connectivity without the control plane being aware of it,
>    and packets are dropped on the floor.



​That not correct if you do it right. If you can reach A via NH1 and NH2
and RS propagates both of those NHs to clients - it is up to clients to
validate those NHs and choose one which they prefer for forwarding at a
given point of time.

RS does not need to be part of that game at all.



> ​   ​
> This document proposes the use
>    of BFD between the two peering routers to detect a data plane
>    failure,


​BFD can be extended to work without protocol, object tracking ​can used,
passive or active probes traversing next hops etc ... but it's a local
matter on the client.

In fact it remains interesting to see what timers are required to handle
BFD to say 1000 peers from a single box.

Now comes BFD security with maintaining different MD5 keys across 1000
peers ! The draft says read RFC5880 and that's what is there.



> ​a​
> nd then uses a newly defined BGP SAFI to signal the state
>    of the data link to the route server(s).
>


​Signalling anything to route servers is not needed. It puts us all back to
late 80s' or early 90s' on how networks were running at that time.


and, if you wander over to the referenced route server docco, you'll see
> that it already deals with alternate paths.
>

​It's not about "dealing with them" ... it is about distributing them to
the clients so clients can use them.


Thx,
Robert​