Routing over Demand Circuits

[Tony Li <[e-mail]>]

   Input to my Conclusion
   ----------------------
   
   1. Path Constraint
   ------------------
   
   In its current state of development, Presumption of Reachability
   REQUIRES that advertisement of routing information AND the routes
   being advertised MUST follow NOT ONLY the same path, BUT utilise
   the SAME Virtual Circuit(s).
   
   This means that advertising of one protocol through another (ie
   encapsulation in TCP) will not work in cases where each protocol
   has its own VC (eg RFC 1356 when protocols are not multiplexed, but
   each have their own VC).
   
This doesn't follow.  Since you are explicitly maintaining a logical
connection even through the VC may be closed, the traffic that you
subsequently send is ALSO over a different VC than the one used by
routing, even for the same protocol.

   2. End-to-End Reliability
   -------------------------
   
   Each routing application must be able to guarantee that messages
   can be sent to and received from its peer application in the remote
   router.
   
   TCP in itself does NOT achieve this.  Each routing application
   needs to know that its peer routing application is functioning.
   Additional mechanisms must be used to achieve this.
   
No protocol can.  How do you insure that the other end of your
connection will speak the same protocol as you, regardless of the
protocol?  Answer: you have to ask.  This is transport independent. 

   3. Stale Information
   --------------------
   
   If there are temporary problems with obtaining VCs, a number of
   routing updates may be queued for transmission by TCP:
   
   1) Eventually Stale information will be propagated and there may be
   further delay(s) before the up-to-date information is sent (eg. if
   there is contention for the VC resource).
   
      In some topologies these glitches could have fairly undesirable
      consequences.
   
   2) Memory will be gobbled up in queued updates.
   
   In my view these two factors completely rule out the use of TCP for
   RIP-like applications.
   
If you take a datagram approach, the alternative is to discard update
information and (somehow?) remember that you must force a full update
exchange when you are able to re-establish connectivity.  You must
implement retransmission anyhow.  And you will have stale information
until you re-establish connectivity.  

   4. Effort to implement a solution 
   ---------------------------------
   
   At the Amsterdam meeting there was a PERCEPTION that the UDP-like
   solution required more support to be added into the routing
   applications than might be the case for an encapsulated TCP
   solution.
   
   However because TCP does not guarantee peer-to-peer reliability for
   EACH routing application the perception turns out to be FALSE.
   
??? TCP does guarantee peer-to-peer reliability.  Or what are you
calling peer-to-peer reliability????

I'm sorry, but I see no reason not to use TCP here.

Tony