[ih] Exterior Gateway Protocol

[Steve Crocker]

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