Requests For Comments ... for the community
Welcome to OpenRFC
Home Full RFC index RFC humour Our technology
<< Previous <<      RFC 613      >> Next >>    
Network connectivity: A response to RFC 603.
A.M. McKenzie. January 1974.

[Direct link][Download PDF version][Download text version]

Network Working Group Alex McKenzie RFC # 613 BBN-NET NIC # 21525 January 21, 1974 Network connectivity: A response to RFC #603 Network topology is a complicated political and economic question with obvious technical overtones. I shall not attempt, in this note, to cover all the possible arguments which might be made, but merely to respond directly to the points raised in RFC #603. 1. The important consideration in deciding whether it is good or bad to have a node (AMES) be four connected is not how many circuits are affected by a node failure; rather one should consider how well the network is still connected after a node failure. For example, if ALL nodes in the network were four-connected I doubt that anyone would argue that this was bad for reliability. The weaknesses are not the three-connected and four-connected nodes but rather the ONE-connected (Hawaii, London) and two-connected nodes. I must agree with Burchfiel's implied argument that it is better to have two adjacent three-connected nodes than to have a four-connected node adjacent to a two-connected node; unfortunately the realities of installing interfaces and common carrier services cause the Network to expand in sub-optimal ways. 2. "Loops" are not good per se, they appear good because the act of making loops increases the connectivity and thereby reduces the effect of multiple failures. Adding more circuits costs ARPA money, both capital cost for IMP interfaces and recurring cost for the circuits. The network group at BBN has suggested to ARPA several times that "connectivity should be increased" but it was only late in December 1973 that we made specific suggestions for the locations of additional circuits. These recommendations were not based on building loops (although they may have that effect) but were based on breaking the long chains of IMPs which have occurred as the Network has grown. ARPA and NAC are now presumably in the process of evaluating our suggestions, and perhaps formulating other possibilities. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 10/99 ] McKenzie [Page 1]


[Home] [Full RFC index] [RFC humour] [Our technology]

Copyright © Inter-Corporate Computer & Network Services, Inc.  All rights reserved.
All trademarks and RFC contents are the property of their respective owners.