RFC 1482 (rfc1482) - Page 3 of 11
Aggregation Support in the NSFNET Policy-Based Routing Database
Alternative Format: Original Text Document
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
These statements mean that AS 42 only wishes to hear announcements
from the backbone about the nets in AS 22 which are explicitly listed
here (i.e., net 192.135.237).
It is also possible, when using the "restrict" keyword, to list
specific "noannounce" lines. Those indicate that all of the networks
listed in the routing table for the AS should be announced except
those listed on the noannounce clauses. (There is also a
"noannouncetoAS" statement[4].)
2.2 New Configuration Features for Aggregation
There will be three new capabilities for which the backbone service
can be configured to support aggregation. The first two allow
aggregates to be accepted and stored in the backbone routing tables
based on announcements by the regional network (autonomous system or
AS) peers. The third allows the announcement of aggregates to the AS
neighbor peers. The following sections give examples of the three
features.
We use the notation to describe an aggregate.
This refers to the IP prefix "net-IP", with a mask which has
"prefix-length" 1's as counted from the high-order end. For example,
is equivalent to [5].
(The form using prefix-length rather than the mask is more compact.)
2.2.1 NSFNET accepts aggregates
In this case the regional peer router is CIDR-capable (i.e., runs
BGP-4) and the announcement comes into the backbone as an IP address
prefix.
To illustrate this in the spirit of sec. 2.1.1:
1:189 2:24 3:267
In this example, independent of the "class" of IP network number, an
aggregate containing network addresses matching a pattern in which
Knopper & Richardson