Summary

  • RFC 1222 proposed placing the subscriber and NSFNET Backbone routing entities in one physical machine, but kept them as two logical domains joined by EGP or BGP.
  • Physical consolidation did not merge configuration authority. Each administration remained responsible for the integrity of its own routing information, and the Ethernet attachment remained a demarcation point.
  • A loopback session or two running daemons did not prove isolation, correct kernel state, forwarding or reachability. The memo itself warned about unwanted interaction through the shared kernel and difficult fault isolation on shared media.

A boundary inside the box

RFC 1222, published in May 1991 by H-W. Braun and Y. Rekhter, was a proposal to make NSFNET Backbone attachment simpler and less expensive. The RFC Editor record classifies it as Informational. The IETF Datatracker preserves it in the Legacy stream. The memo explicitly says it does not specify an Internet standard.

Its proposal only makes sense against the routing history it recounts. In the 56 Kbps first phase of NSFNET, Fuzzball backbone routers used the Hello Protocol while mid-level networks commonly used RIP. A gated process translated between those environments. From a distance, backbone, regional and campus routing looked like one system in which information circulated freely.

That apparent unity carried hidden costs. Metric changes at one edge could pass through several administrations to the other edge. Event-driven changes increased fluctuation. As the topology gained more connections, limited controls over dynamic routing information made loops easier to form. One shared information surface had confused interconnection with common control.

Exterior routing created insulation

The T1 second phase answered by strongly separating the backbone IGP from the IGPs of attached clients. Each administration could run its own internal protocol. At the boundary, EGP—and later BGP—carried reachability between the domains. The prior NSFNET architecture and policy-routing design supplied databases, representation agreements, configured preferences and controls around that exchange.

The separation narrowed propagation. EGP chiefly exposed network up/down transitions instead of exporting every internal metric fluctuation. Backbone routes could be engineered in advance from a centrally checked configuration database. This was not proof that every route was authorized or that a packet would travel. It was an architecture that gave each side a place to reject, translate and account for information.

The operational price was hardware and expertise at the subscriber site. A subscriber normally had to install its own routing peer on a subnet shared with the local NSFNET node. That peer joined the subscriber IGP and maintained an EGP or BGP session with the backbone side. For smaller sites in the T3 expansion, the extra equipment and more complicated routing environment could make a correct boundary unnecessarily expensive.

Remove a chassis, not a jurisdiction

RFC 1222 separated the logical requirement from the equipment chosen to implement it. Two logical routing entities remained essential. One participated in the subscriber IGP; the other participated in the backbone IGP. They exchanged information through an inter-domain mechanism. Nothing in that requirement demanded two physical routers.

The memo therefore proposed putting both entities in one machine. An example used two routing daemons on a Unix exterior node, talking EGP or BGP through the local loopback interface or internal IPC. This was not an early claim that every process in a box shared one truth. It was the opposite: the exterior protocol remained useful precisely because the processes represented different administrative routing systems.

BGP as specified in RFC 1163 exchanged reachability between autonomous systems. Running that exchange over loopback shortened the physical path to almost nothing. It did not change the authority of the messages. A route learned across that internal boundary still needed import policy, provenance and a responsible configuration owner.

The common kernel could betray the diagram

A neat diagram of two daemons can overstate isolation. RFC 1222 warned that care was required so both daemons would not interact with the system kernel simultaneously in unwanted ways. The shared forwarding table, interfaces and process environment were a common failure surface.

That warning draws a precise evidence ladder. Two processes running proves process presence. A successful local BGP session proves a bounded control exchange. Accepted routes prove a decision by one process. Installed routes require a kernel observation. Forwarding requires data-plane evidence. Reachability requires observation beyond the box. None of the earlier records silently contains the later one.

The proposal also retained strong firewalls between IGP domains and called for routing information to be tagged with exterior-domain information when it crossed. A tag made origin context portable. It did not authenticate the route, authorize every use or guarantee that later software preserved the tag.

Configuration stayed with the party it described

Physical consolidation did not centralize all configuration. RFC 1222 asked for distributed control. The NSFNET Backbone organization and the attached-network provider were each responsible for the integrity of their own routing information. The regional client could supply the configuration for the daemon that participated in its IGP, preserving control over what entered that domain.

The Ethernet attachment remained the administrative and operational demarcation. That choice is revealing. The processes could share a machine, but responsibility still needed a visible line: who authored which inputs, who operated which interface and who had authority to change which routing view.

Integrity responsibility was not an integrity observation. The source assigned duties; it did not provide a log proving that either party discharged them in a particular deployment. Nor did a centrally checked backbone database prove that the subscriber-side daemon installed the intended routes.

A moving demarcation needed better fault evidence

The long-term alternative moved the boundary closer to the backbone core. An exterior node could participate fully in the subscriber IGP while the backbone IGP stayed within the C-NSS cloud. That arrangement required two administrations to manage the physical medium between core and exterior nodes.

The standard for success was not merely that a serial link came up. Management and fault isolation needed to approach the clarity of an Ethernet demarcation. PPP and stronger serial-line management might help, yet heterogeneous equipment made it difficult to identify where a hardware problem belonged.

RFC 1222 thus treated the boundary as an evidence system, not a line drawn for organizational comfort. Consolidation was valuable when it removed unnecessary equipment. It became dangerous when one box encouraged operators to collapse route origin, configuration authority, kernel state, physical fault and delivered service into a single unexamined claim.

Sources