[ih] Exterior Gateway Protocol

[Vint Cerf]

in the case of BGP, TCP is just a protocol running on IP and that
network management  "stack" is independent of the stack seen by client's of
the standard stack.

lI didn't see it that way at first but got more comfortable with the sense
that network management stack is distinct

v


On Mon, Sep 7, 2020 at 10:41 AM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> Related to but not quite the same as provability is the cold start
> problem.  If there are layer violations, it’s not possible to restart the
> system from scratch layer by layer.
>
> Fortunately, the entire system is big enough that it doesn’t crash
> completely.
>
> Sent from my iPhone
>
> > On Sep 7, 2020, at 10:14 AM, Noel Chiappa via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > 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
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965

until further notice