Routing over Demand Circuits

[Tony Li <[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.

   >   ?  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.

   >Do you REALLY want to solve this problem?  IMHO, you've crossed the
   >cost/benefit curve.

   Yes! Solving this problem comes for free with my solution.  It would be
   foolish to turn your back on this more encompassing solution - for what?

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 can argue about the implementation costs til the cows come home.
   Neither of us disagree that some form of solution can be provided
   through UDP or TCP.   Any difference in cost is likely to be both
   small and implementation dependent - and IMHO irrelevant.

IMHO, it's very relevant.

   We want the best solution - which on the evidence to date is 'UDP' based.

That depends on your value for "best".  I find the cost of the pure
datagram solution to be exhorbitant.  And there's a cheap solution
immediately available.

   >   I agree.  No assumption should be made that all pairs of routers
   >   support routing the same protocols.  But they should also not
   >   assume that the same set of protocols will continue to be routed
   >   forever.  That is one of the reasons for the acknowledgement coming
   >   from the peer routing application.
   >
   >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). 

   Err sorry.  Who's suddenly doing the ACKing?

You have a reliable protocol (at some level -- either with TCP or a
datagram mode).  I'm _assuming_ that you were intending to sequence
your updates in the datagram model and ACK them.  If you are NOT
intending to do this, then I don't see how you can claim that it's
reliable. 

   I had assumed the whole point of your suggestion of using TCP was to AVOID
   (having to write code for) the routing application having to do any ACKing.
   What *is* the point of your suggestion?

My point is that I don't want to have to create n different datagram
based, reliable, sequenced transport protocols.  Even if we create one
and xerox it (oops... photographically reproduce it) for the other
protocols, it is an annoyingly large bit of overhead.

Tony