[ih] Exterior Gateway Protocol

[Noel Chiappa]

Wow, you all have been sending a lot of email. Let me package a few replies
together, to minimize my list traffic.

    > From: Joseph Touch

    > Can you tell us more about what part of BGP's use of TCP was
    > controversial at the time?

I don't directly remember what the concerns were, but I think I can probably
re-create them. (Jack Haverty's comments are very epropos too.)

At the time it was generally held in the OS field (where most of us had come
from - networking was just getting started as a distinct field) that
dependency loops among subsystems (i.e. subsystem A calls on B, which
calls on C, which in turn calls on A) were bad.

Some people may have had issues with provability (which was somewhat popular
at the time), but I think for a lot of people, it was just more a general
sense that i) it made it hard to fully understand how the system worked, and
ii) it could give rise to problems, e.g. deadlocks.

A good sense of the thinking on the topic can be found in Dave Reed's
master's there, "Processor Multiplexing in a Layered Operating System":

  http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-164.pdf

from 1976. It is mostly concerned with a dependency loop between
processes/process-switching and virtual memory (some of the OS's process state
may be paged; and paging may have to call on process switching when a process
is paused for a page fault), but has a good overview of the contemporary
thinking about dependency loops.

Running BGP on top of TCP brings in the same kind of relationship: BGP is in
some sense 'part of' the internetworking layer, and TCP is definitely a
client of that layer, so running BGP on top of TCP is, de facto, a dependency
loop - at least from a _subsystem structural_ viewpoint.

In actual practise, problems are generally avoided by avoiding _operational_
dependency loops: e.g. IBGP does depend on the IGP to get packets between
border routers of the AS, but that just means that EGP depends on the IGP, as
it always did. And for EGP between border routers of two AS's, they must be
on a common network, i.e. no routing needed.

However, I believe that most people were made uneasy by the subsystem
structural dependency loop of BGP on TCP.  We'd had some experience of
successfuly working with subsystem _structural_ dependency loops, with ICMP
(which is in theory part of the internetwork layer) running on top of IP,
without any major problems operationally _in the use cases which we had for
it_ (which did not generally involve _operational_ dependency loops).

That gave us confidence that the BGP on TCP case was probably workable (as
long as we avoided _operational_ dependency loops), but at the same time we
did know that we were pushing the envelope. Then again, the entire packet
communication field was pushing the envelope, as the Bell people were always
happy to remind us, so we held our breath and jumped!


    > From me:

    > I think in a really large network, doing congestion avoidance in one
    > subsystem, long with path selection, is not workable. I think it should
    > be done separately 

Of course, I doubt we'll ever do congestion avoidance (i.e. dynamically use
an alternate path); these days the style seems to be to add bandwidth on
gongested paths.


    > From: Scott Brim

    >> I have this vague memory that Scott Brim may have been at an FGP
    >> kick-off meeting

    > Either the first or the second. It was the third IETF.

The meeting I am vaguely remembering was at Proteon.

	NOel