Re: Routing over Demand Circuits

Charlie Slater <cslater@telebit.com> Wed, 01 September 1993 19:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11272; 1 Sep 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11268; 1 Sep 93 15:29 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa21925; 1 Sep 93 15:29 EDT
Received: by atlas.xylogics.com id AA15925 (5.65c/UK-2.1-930726); Wed, 1 Sep 1993 15:27:25 -0400
Received: from apache.telebit.com by atlas.xylogics.com with SMTP id AA01379 (5.65c/UK-2.1-930726); Wed, 1 Sep 1993 15:27:13 -0400
Received: from mondavi.sunnyvale.telebit.com by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA15237 to ietf-rip@xylogics.com; Wed, 1 Sep 93 12:26:55 PDT
Received: by mondavi.sunnyvale.telebit.com (5.67/1.37) id AA08854; Wed, 1 Sep 93 12:26:49 -0700
Date: Wed, 01 Sep 1993 12:26:49 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Charlie Slater <cslater@telebit.com>
Message-Id: <9309011926.AA08854@mondavi.sunnyvale.telebit.com>
To: gerry@spider.co.uk
Subject: Re: Routing over Demand Circuits
Cc: ietf-rip@xylogics.com

> >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?
>
>
> The short answer is yes - in theory.   But me thinks you are expecting
> the solution to scale too much.   The number of destinations must be
> comparable to the number of ports - not two order of magnitudes larger!

Gerry,

Several of our customers have configurations like this now.  One
customers plans to have a central site with 10 32-port routers and
10,000 possible destinatinations.

To be worth implementing, the protocol extension needs to scale.  I
Am not sure what the best way to do this is, but clearly what is
proposed in the draft will not work.

How about something like this?  For destinations running the extension:

    send updates only when requested.

    support to types of requests:

	reply with a complete list of routes.

	reply only with changes:  New routes and routes to be
	deleted (poisoned by setting the metric to 16).  "Permanent"
	routes stay unless poisoned by an update.

For connections for which this protocol is not appropriate can run
RIP protocol used on LANs.

The way I would use the extension is if the link were brought up for
some other reason, each side would request an update from the other.
Current routing information would be available if the link were
brought up for, say, transferring a file, but RIP packets would
not be sent just because one sides routing table changed.

It might be a good idea to require a site to send a request after
establishing a connection.


> PS: When I started writing I assumed your example referred to 32 dial up lines
> operated as a hunt group on the same logical network.

Yes.  I meant a hunt group, 32 dial-up lines and one LAN interface,
the 2500 destinations are mostly single hosts small LANs.  Some are
subnets of the same Class B network and some are on different Networks.
Some of the routinely call other sites, other remote sites only
route to the central site unless it is down in which case they
route to a backup site.

charlie