Routing over Demand Circuits

Gerry Meyer <gerry@spider.co.uk> Tue, 17 August 1993 12:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01445; 17 Aug 93 8:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01441; 17 Aug 93 8:07 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa04678; 17 Aug 93 8:07 EDT
Received: by atlas.xylogics.com id AA01995 (5.65c/UK-2.1-930726); Tue, 17 Aug 1993 08:05:35 -0400
Received: from relay.pipex.net by atlas.xylogics.com with SMTP id AA06370 (5.65c/UK-2.1-930726); Tue, 17 Aug 1993 08:05:26 -0400
Received: from 134.191.64.3 by relay.pipex.net with SMTP (PP) id <27188-0@relay.pipex.net>; Tue, 17 Aug 1993 13:03:43 +0100
Received: by widow.spider.co.uk; Tue, 17 Aug 93 13:09:42 +0100
Received: by camel.spider.co.uk (5.61/1.34) id AA07805; Tue, 17 Aug 93 12:59:18 +0100
Date: Tue, 17 Aug 1993 12:59:18 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gerry Meyer <gerry@spider.co.uk>
Message-Id: <9308171159.AA07805@camel.spider.co.uk>
To: gerry@camel.spider.co.uk, ietf-rip@xylogics.com, tli@cisco.com
Subject: Routing over Demand Circuits

>   * 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