Routing over Demand Circuits

[Gerry Meyer <[e-mail]>]

>   * I have used up memory corresponding to M * N * Size of update message(s).
>     If I cannot get memory for the latest update I've blown it.
>
>A competent implementation has to deal with this regardless.

Which is strightforward to handle (but unlikely to occur) in a UDP solution.
But is a major headache in a TCP solution - which has to be added to your
cost to implement a TCP solution.

>   >   ?  Processing the stale information and then overwriting it with
>   >   current information is not a concern.  If this was a serious problem,
>   >   BGP would have already stopped working a long, long time ago.
>
>   The *key* difference is BGP does incremental updates:
>
>   * so all things being equal (similar overall number of routes) requires
>     to transmit less 'routes' than RIP in the event of an update being
>     required.
>
>   * but more importantly the 'stale' information MUST be transmitted because
>     it is *required* for routing table consistency.
>
>Yes, BGP has to do this.  I still don't see that it's cost effective
>to do otherwise for RIP.

Because with prolonged delays and alternative routes it can lead to subtle
side-effects.

A bad solution is NOT a cost effective solution.

>Gerry, we don't choose to solve all problems.  You have to make
>engineering tradeoffs.  The tradeoff, IMHO, is to do a single
>transport and not re-invent the wheel for each protocol.

We strive to produce better solutions.

Your statement from an earlier exchange -

>   >So?  I still don't understand this.  Look, all you have to do is to
>   >mux stuff on top of your TCP connection.  If the AT agent went away,
>   >for example, the AT routes don't get ACKed (at the routing protocol
>   >level). 

- implies that even with a TCP solution you believe the application
has to sequence, retransmit and ack.

Looks like Xerox shares would be a safe bet either way.

	Gerry