Routing over Demand Circuits

[Tony Li <[e-mail]>]

Gerry,

   If the protocols are NOT multiplexed within a VC then each routed
   protocol must be considered to have a different LOGICAL connection.

   Consider a somewhat constrained example:

   Suppose I have an X.25 interface with only two logical channels
   (VCs allowed) and each protocol has its own VC.

   IP is using one VC and IPX is using the other and both VCs are busy
   and neither can be pre-empted.  The peer router is reachable for IP
   and IPX and both routing protocols consider the route to be UP.

   Now if Appletalk traffic comes along and tries to use the link it
   will be unable to obtain a VC.  The Appletalk RIP variant will get
   a circuit DOWN message and start timing out its routes.  If it
   times out, Appletalk considers the route to be DOWN - because the
   resource cannot be obtained for Appletalk currently.

Oh yuck.  Well, I could argue that the connection manager should then
dissociate between the transport used to carry the protocols and the
VC for the protocol.  Thus the VC for AT being wedged could cause AT
routing to appear to be down, even if the routing information via IP
was still active.  There's ample precedent for using out of band
information in a routing decision.

Of course the flip side is that if IP is blocked, you lose your
transport.

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

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

   I also have a concern that updates may fail to get through when the
   TCP connection is not established - during TCP call collisions at
   opening, during closing etc.  Remember that the routing
   application(s) are not managing the calls directly themselves.

So?  There are many things that will cause packets to drop.  You will
not eliminate this problem by rolling your own.

   Its pretty straightforward.  The RIP update always consists of the
   full current information, so there is no need to store earlier
   stale information which has not been acknowledged.

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

   It only guarantees peer-to-peer TCP reliability (see point 2,
   above).

I'm still lost.

   I would also add there may be (no, are) routers out there which
   don't have a TCP stack or particularly require to use one.  While I
   am pro-TCP/IP, is imposing a TCP/IP stack on others in this
   instance not being a bit dogmatic?

No, it's being practical.  Despite what the NM directorate will tell
you, it's very tough to manage a router with SNMP.  You need telnet.
So you have TCP in the box already.  And you needed it to do BGP as
well.  Find me a router with significant market share that doesn't do
telnet....

I call reinventing a transport protocol per protocol stack for the
sake of an architectural principle a bit dogmatic.

   Have I convinced you yet?

Not in the least.

Tony