Aggregation Support in the NSFNET Policy-Based Routing Database
RFC 1482

Document Type RFC - Historic (June 1993; No errata)
Authors Steven Richardson  , Mark Knopper 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1482 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                   Mark Knopper
Request for Comments: 1482                      Steven J. Richardson
                                                           June 1993

    Aggregation Support in the NSFNET Policy-Based Routing Database

Status of this memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is


   This document describes plans for support of route aggregation, as
   specified in the descriptions of Classless Inter-Domain Routing
   (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network
   Service.  Mechanisms for exchange of route aggregates between the
   backbone service and regional/midlevel networks are specified.
   Additionally, the memo proposes the implementation of an Aggregate
   Registry which can be used by network service providers to share
   information about the use of aggregation.  Finally, the operational
   impact of incorporating CIDR and aggregation is considered, including
   an analysis of how routing table size will be affected.  This impact
   analysis will be used to modify the deployment plan, if necessary, to
   maximize operational stability.

1. Introduction

   The Internet network service provider community and router vendors
   (as well as the IESG and various IETF working groups) have agreed
   that the time for deployment of route aggregation is upon us. This
   topic has been discussed in the BGP-D, NJM and ORAD working groups at
   several IETF meetings; it was a discussion topic of the NSFNET
   Regional Techs' Meetings in January and June, 1993; and it was also a
   topic of several meetings of the Federal Engineering Planning Group
   and Engineering and Operations Working Group of the Federal Network

   All have generally agreed that Summer, 1993 is the time to enable
   BGP-4 and CIDR aggregation.  Each of the parties is responsible for
   its own aspect of CIDR implementation and practice. This memo
   describes Merit's plans for support of route aggregation on the
   NSFNET, and a proposal for implementing a database of aggregation
   information for use by network providers.

Knopper & Richardson                                            [Page 1]
RFC 1482              Routing Aggregation Support              July 1993

2. Aggregation Support by the Backbone Service

   The NSFNET backbone service includes a Policy-Based Routing Database
   system which currently holds the set of network numbers that are
   accepted by the backbone service with a list of Autonomous System
   numbers from which announcements of these network numbers are
   expected.  In order to implement CIDR, the database system will be
   modified to allow aggregation of routing information to be

   The NSFNET will (initially) not support de-aggregation on its
   outbound announcements. See section 2.3.

2.1 Current Configuration Capabilities

2.1.1 Inbound Announcements

   An example of the way a network number is currently configured is as

         35      1:237   2:233   3:183   4:266   5:267  6:1225

   This shows that network number 35 (ie., a class A net
   number) is configured on the T3 backbone such that routing
   announcements are expected from up to 6 autonomous systems. The
   primary path is via AS 237, secondary is via AS 233, etc.

2.1.2 Outbound Announcements

   Currently the NSFNET database has a list of AS's or network numbers
   for each neighbor AS that are announced by the backbone to that AS.
   These announcements are specified currently by "announcetoAS"
   statements--which implement policies submitted by midlevels to
   Merit--and then included in the ANSnet router configuration files.
   There are two forms of these statements.  The first form uses the
   "norestrict" clause and indicates that all of the network numbers
   within each AS in the list should be announced to the neighbor
   midlevel AS. For example:

         announcetoAS 42 norestrict ASlist 22 26 38 60 68

   In this example, the NSFNET is configured to announce to neighboring
   midlevel AS 42, all networks in the routing table that were announced
   from AS's 22, 26, 38, 60 and 68.

   If the "norestrict" keyword is changed to "restrict", this indicates
   that an explicit announce list of network numbers for the AS is
   specified in the configuration file. The NSFNET will only announce

Knopper & Richardson                                            [Page 2]
RFC 1482              Routing Aggregation Support              July 1993

   network numbers that were announced by the AS's in the list, *AND*
   which appear in the "restrict list" of network numbers submitted
   separately by the midlevel.

      For example,

         announcetoAS 42 restrict ASlist 22

         announce 192.135.237 <other info>
Show full document text