Routing over Demand Circuits

[Gerry Meyer <[e-mail]>]

Tony,

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

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.


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

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.

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.

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

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.

Retransmission can simply consist of a timer/flag.  If the routing
information has been updated between retransmissions - all to the good.

A circuit UP message initiates a rip request when the routing application
has timed out routes from that next hop router.

>You must
>implement retransmission anyhow.  And you will have stale information
>until you re-establish connectivity.  

Transmitting of stale (changed) information via TCP is the real problem
I was trying to raise since this will ripple through a triggered RIP
implementation (whereas not-yet-updated unchanged information will just
sit there relatively benignly).

Indeed having this stale information to transmit could cause a bottleneck
on the WAN interface which in itself could aggravate the problem.

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

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

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

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?

Have I convinced you yet?

	Gerry