Re: Routing over Demand Circuits
Charlie Slater <cslater@telebit.com> Thu, 26 August 1993 17:15 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07836; 26 Aug 93 13:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07832; 26 Aug 93 13:15 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa16546; 26 Aug 93 13:15 EDT
Received: by atlas.xylogics.com id AA27337 (5.65c/UK-2.1-930726); Thu, 26 Aug 1993 13:14:47 -0400
Received: from apache.telebit.com by atlas.xylogics.com with SMTP id AA22822 (5.65c/UK-2.1-930726); Thu, 26 Aug 1993 13:14:37 -0400
Received: from mondavi.sunnyvale.telebit.com by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA03885 to ietf-rip@xylogics.com; Thu, 26 Aug 93 10:13:02 PDT
Received: by mondavi.sunnyvale.telebit.com (5.67/1.37) id AA29800; Thu, 26 Aug 93 10:13:00 -0700
Date: Thu, 26 Aug 1993 10:13:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Charlie Slater <cslater@telebit.com>
Message-Id: <9308261713.AA29800@mondavi.sunnyvale.telebit.com>
To: gerry@spider.co.uk
Subject: Re: Routing over Demand Circuits
Cc: ietf-rip@xylogics.com
I have some questions. Your draft identifies some problems to solve: > o The number of networks to be connected (N) on the WAN can easily > exceed the number of simultaneous calls (M) which the interface > can support. If this happens the routing 'broadcast' will only > reach M next hop routers, and (N - M) next hop routers will not > receive the routing update. > For now, call this the: "Many Destinations Problem". > This memo targets two areas: > > o Eliminating the overkill inherent in periodic transmission of > routing updates. Call this the "Too Many Updates Problem" > > o Overcoming the bandwidth limitations on the WAN: the number of > simultaneous VCs to next hop routers and restricted data > throughput which the WAN link can support. > Call this the "WAN Bandwidth Problem" Many Destinations: I am not clear on how the this proposed protocol solves any of these problems. Let's start with the Many Destinations Problem. Consider a "central site" router with 32 serial ports hooked up to various low-speed (9600bps to 128Kbps) switched circuits. This router knows how to get to 2500 destinations. The draft says, > The approach taken is to modify the routing protocols so as to send > information on the WAN only when there has been an update to the > routing database OR a change in the reachability of a next hop router > is indicated by the task which manages connections on the WAN. Does this mean that when there has been a routing database update or a change in reachability, that this 32-port router must call all 2500 destinations to send each of them a routing update? Too Many Updates: As I read the draft, the only control on the number of updates is to put in a delay. Say the delay is one hour and the routing database changes at least once per hour (not unlikely in the case of a busy, 32-port router). Every site gets called once per hour. In practice this is going to yield the worst of both worlds: a lot of wasted calls and a long delay for sites that need the update. How does one prevent this? I guess what I expected to find was something that said, "Here are the destinations (networks or hosts) that 'I' care about. Call me if these routes change. Otherwise, wait until I ask 'you' for an update." It might be nice to have something that said, "Never send me an update for these destinations." Is there a way to do this? WAN Bandwidth Problem Explain to me how this 32-port router that has at least 2500 routes in its table is going to send this information efficiently over a low speed link when one of these routes has changed. With the router send only the route that has changed or will it send all routes? This section of the draft seems to indicate that all routes must be sent. > Entries learned from a triggered response on the WAN are 'permanent'. > They MUST not time out in the normal course of events. The entries > state MUST be changed to 'temporary' by the following events: > > o The arrival of a routing update containing the entry set to > unreachable. > > The normal hold down timer MUST be started, after which the entry > disappears from the routing database. > > o The arrival of a routing update with the entry absent. Won't an update containing a partial list of routes cause the absent entries to become "temporary" and is it possible for "temporary" entries to go away? charlie cslater@telebit.com
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Tony Li
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Tony Li
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Gerry Meyer
- Re: Routing over Demand Circuits Art Berggreen
- Routing over Demand Circuits Tony Li
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Tony Li
- Re: Routing over Demand Circuits Fred Baker
- Routing over Demand Circuits Gerry Meyer
- Routing over Demand Circuits Tony Li
- Routing over Demand Circuits Gerry Meyer
- Re: Routing over Demand Circuits Fred Baker
- Routing over Demand Circuits Gerry Meyer
- Re: Routing over Demand Circuits Charlie Slater
- Re: Routing over Demand Circuits Gerry Meyer
- Re: Routing over Demand Circuits Charlie Slater
- Re: Routing over Demand Circuits Gerry Meyer