Why doesn't BGP... -Reply

> > >SS7 (Signalling System 7) is a connectionless packet switched technology
> > >used to control the setup and teardown of circuit switched calls.
> > >Originally is was used as a database query technology to make 800
> > >numbers portable across carriers. If this did not make sense I can descib
> e
> > >it in a little mnore detail offline.
> >
> Vadim makes my point better than I did - SS7 etc. make their routing
> decision OTO once per call (on call setup). IP makes it once per packet.
> Therefore you can put a lot more effort into finding the correct route
> if you only have to perform the calculation once. This was an algorthmic
> point not a network/transport layer point.
> Alex Bligh
> Xara Networks

The route computation is made by the routing protocol and is only made
when a route changes. Maybe you know of a router implementation
where the forwarding code checks the BGP and OSPF paths for every
packet, but I don't know of any that work that way.

If routers were stable, routers would make all of their routing
decisions within minutes of power up and never change those decisions.
Forwarding is then based on the table builtbased on those decisions.

Yes I know - I meant IP has to recalculate whenever its given new information
as it makes a forwarding decision once per packet. Apologies for my
inablity to write.

The original question was "why doesn't BGP respond to changes in line
congestion etc. like SS7 does". I supposed my answer assumed that the
time between significant changes of congestion "anywhere" on the internet
(i.e. time between changes to BGP calc) would be an order of magnitude
smaller than length of average telephone call. This may be to do
with (possibly unjustified who knows) perception of instabililty
of a system with all sorts of types of feedback controlled by
disparate groups of varying technical expertise with different hardware
etc. etc.

Though your point about BGP is accurate, it assumes
the amount of flap remains constant. As I would guess most congestion
appears within ASes (as opposed to between them), in order for congestion
response to be usefully implemented it would have to alter the advertised
metric etc. when congestion *within* that AS changed (so if ISPs
connection to the Sprint NAP becomes congested it sends the routes
with a different metric or something at Sprint and in the opposite
direction at MAE-East). This would remove a lot of the isolation between
BGP and internal routing protocols that makes BGP stable(ish).

Call setup happens every time a connection is setup. Even as much as
routes flap in the Internet, the load on the routers (ones that
actually work, mythical) only affects mostly stable routes by slowing
their convergence when they make their very rare bounce. That's why
IP routing scales as well as it does and switches using comparable
processors have already exceeded call setup rates in limited

See point about assuming that the suggestion would have no effect on
the amount of withdrawls/announcements. But heh, we are arguing about
hypotheticals and counterfactuals as this is a cul-de-sac. You
list alternative strategies greater minds than mine have come
up with below ...

IP routing has an scaling advantage over call setup. Call setup can
take advantage of the lowest loaded path at the time of setup,
providing a better chance to load balance (ala PNNI). The VC table
has a speed forwarding advantage over the IP radix tree. The radix
tree may have a space advantage due to aggregation. That in a
nutshell is the IP vs ATM flamewar (did I miss anything - ommisions
private mail unless it was major). The interest in IP switching
(CSRs, tag switching, IP switching proposal de jour) comes from a
desire to combine the best of the two.

Alex Bligh
Xara Networks