Re: Routing over Demand Circuits

[Gerry Meyer <[e-mail]>]

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


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!

Or more mathematically if a VC is typically open N seconds for a routing
update (before going idle or being pre-empted), then for a 180 second
RIP timeout you cannot expect your 32-port router to be able to support
more than 32 * 180/N destinations.  And I would leave a further margin
of safety.

For this type of problem if you read very carefully between the lines,
you might deduce that with a bit of sleight-of-hand you can operate
a scheme with statically declared routes to destinations over the WAN
and with routing updates switched OFF on a WAN circuit.  The static routes
'time out' and appear with the circuit UP/DOWN states reported by the
circuit manager and are appropriately advertised elsewhere.

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

Does my answer above help?

I suggest no delay other than the 'dribbling' of a routing 'broadcast'
to the WAN which will help to avoid congestion on an X.25 link every
time there is an update - and unnecessary code munching looking
for a pre-emptable VC.  The update must expect to dribble out to all
destinations in a short period (again certainly less than RIP's 180 seconds).

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

See static routes above.

I'm sure there are manufacturer-specific policy enhancements which
can be applied.

Many of them can reside in the circuit manager (which I don't describe
in the I-D).   For example we allow VCs to peer routers to be assigned
a specific priority ('I' care more/less about) as well as having
configurable idle and pre-emption timers.

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

ALL routes MUST be sent if running the routing protocol on the circuit.
That is why the receiver of the update waits for the complete set of
fragments to arrive before deducing what is missing and committing
the information to its routing database.

	Gerry

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.
On re-reading it, perhaps you meant something like 32 X.25 connections to
different logical networks.  If this is the case then a lot can be done
with selective static routes and sub-netting, but you may want a different
routing protocol with a strong policy content.
I have provided some input to the latest BGP-4 application draft - I don't
think issued yet - on use with circuit managers which would be more
appropriate to a 32 connection X.25 example.

	G