Internet DRAFT - draft-ietf-bgpdepl-nsfnet-support
draft-ietf-bgpdepl-nsfnet-support
Network Working Group Mark Knopper
INTERNET DRAFT Merit/NSFNET
March 1993
Aggregation Support in the NSFNET Policy Routing Database
Status of this memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
0. Abstract
This memo describes plans for support of route aggregation, as
specified in the descriptions of Classless Inter-Domain Routing [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 and 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.
1. Introduction
The Internet network service provider community and router vendors
have agreed that the time for deployment of route aggregation is very
near. At the IETF meeting in November, 1992, this topic was discussed
in the BGP-D, NJM and ORAD working groups; it was a discussion topic
of the NSFNET Regional-Techs Meeting in January, 1993; and it was
also the topic of the March, 1993 meeting of several network service
providers and router vendors (see meeting summary for this recent
meeting in [3]).
All have generally agreed that Summer, 1993 is the time to enable
BGP-4 and CIDR aggregation. Each of the parties are responsible for
their own aspect of CIDR implementation and practice. This memo
Expiration Date September 1993 [Page 1]
RFC DRAFT March 1993
describes Merit's plans for support of aggregation on the NSFNET, and
a proposal for implementing a database of aggregate information for
use by network providers.
2. Aggregation Support by the Backbone Service
The NSFNET backbone service includes a Policy 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. For the
CIDR implementation the database system will be modified to allow
aggregation of routing information to be configured. When the NSFNET
service announces routes to regional peers, de-aggregation will not
be done. If a peer needs to receive full routing information the peer
should run the BGP-4 (or later IDRP) protocol which supports CIDR.
2.1 Current Configuration Capabilities
An example of the way a network number is currently configured is as
follows:
35 1:237 2:233 3:183 4:266 5:267
Or, using the syntax proposed by the Yu, Chen and Rekhter in "Inter-
Domain Routing Policy Description and Sharing" [4], this would be
better specified as:
ACCEPT dst 35 and AS_path 237 = 1
ACCEPT dst 35 and AS_path 233 = 2
ACCEPT dst 35 and AS_path 183 = 3
ACCEPT dst 35 and AS_path 266 = 4
ACCEPT dst 35 and AS_path 267 = 5
This shows that network number 35 (ie. 35.0.0.0, a class A net
number) is configured on the T3 backbone such that it can be
reached via 5 autonomous systems. The primary path is via AS 237,
secondary is via AS 233, etc.
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 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:
Expiration Date September 1993 [Page 2]
RFC DRAFT March 1993
2.2.1 NSFNET accepts aggregates
In this case the regional peer router is CIDR-capable (runs BGP-4)
and the announcement comes into the backbone as an IP address prefix.
An example of the first method is as follows. The syntax for ACCEPT
can be modified to handle aggregates as well as single networks.
ACCEPT dst <192.64.128 17> AS_path 189 = 1
ACCEPT dst <192.64.128 17> AS_path 24 = 2
ACCEPT dst <192.64.128 17> AS_path 267 = 3
Or a more compact way of storing the info might be more similar to
the current NSFNET database:
<192.64.128 17> 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
the first 17 bits match the prefix 192.64.128 will be accepted in
announcements to the NSFNET service. Primary path to destinations
covered by the prefix is expected via AS 189, secondary via AS 24,
etc.
2.2.2 NSFNET announces aggregates
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 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 list of network numbers for the AS's in the list is
specified in the configuration file. The NSFNET will only announce
network numbers that were announced by the AS's in the list, *AND*
that appear in the "restrict list" of network numbers submitted
separately by the midlevel.
This system will continue to work once aggregation is implemented.
The norestrict (or equivalent keyword once the new software is
deployed) function will specify that all network reachability
Expiration Date September 1993 [Page 3]
RFC DRAFT March 1993
information received from a set of Autonomous Systems, including any
aggregates, will be announced.
Depending on implementation in the gated software, it may also be
possible to provide more specific restrictions on which aggregates
reachable within an AS will and which will not be announced to a
neighbor AS. Again using syntax similar to what is described in the
RPDL paper, the following examples can be used to describe outbound
aggregation policy:
ANNOUNCE dst <192.64.128 17> to 22
The above specifies that the given aggregate is announced to neighbor
AS 22.
ANNOUNCE * AND (! dst <193 16>) to 42
The above example uses a logical expression style and specifies that
all ("*") networks or aggregates with the exception of 193.0.0.0 mask
255.255.0.0 are announced to neighbor AS 42.
More elaborate announcement policies can be imagined. This discussion
provides examples of what might be available but it has not been
resolved yet just what capabilities will be offered initially.
2.2.3 NSFNET aggregates by proxy
The other method is where the backbone is configured to perform
aggregation on behalf of a CIDR-incapable regional. An example of
this aggregation technique is:
AGGR <192.64.192 AND 192.64.129> => <192.64.128 17>
ACCEPT dst <192.64.128 17> and AS_path 189 = 1
ACCEPT dst <192.64.128 17> and AS_path 267 = 2
In this example, the same class-independent set of IP addresses will
be stored and propagated within the backbone as an aggregate under a
set of conditions. This example has the conditions such that when
both networks 192.64.192 and 192.64.129 are made to the backbone
(through either AS 189 or AS 24 or AS 267) it will aggregate the
whole block. If only one of the networks is announced to the
backbone, no aggregation will be performed. In this case additional
ACCEPT clauses may be present which allow acceptance of the single
network numbers.
Expiration Date September 1993 [Page 4]
RFC DRAFT March 1993
3.0 Aggregate Registry
In discussions with network providers it has become apparent that
there is a great need for sharing of aggregate information globally.
In addition to implementing the capability of including aggregation
information in the NSFNET Policy Routing Database (as described in
section 2), there is a need to have a separate database that will
allow aggregate information from any Autonomous System to be stored
and made available for easy electronic retrieval. The information can
be used for routing coordination and policy configuration in the
larger inter-domain context.
One of the expected uses of such a database is to help determine the
granularity of aggregation of network reachability information with
respect to policy. It may be desirable in some cases to aggregate
broadly, for example all networks whose numbers conform to a binary
prefix pattern within an entire nationwide network. This case may be
rare since it may be unlikely that there is a backbone whose routing
policy is the same for all of its constituent networks. Some of this
depends on how network number allocation has been handled, or whether
the network provider has renumbered its client networks to conform to
CIDR aggregation boundaries. Rules for network number allocation with
CIDR are discussed in [5] and [6].
Merit proposes to implement an "Aggregate Registry" to provide
sharing of aggregate information for the Internet inter-domain
routing community. Initially this will be a simple database without
much structure. It is not intended to hold only aggregates which are
announced or accepted by the NSFNET service, rather it should be a
community registry that all will be invited to use and make use of.
The Aggregate Registry will consist of a list of aggregate
announcement statements. Each statement consists of three types of
information, along with contact information:
1) The aggregate identifier, consisting of a network number prefix
and the prefix length. For example <192.29.128 16>.
2) The source AS number for the aggregate. That is, the AS number
of the network service provider that initially aggregates the
network reachability information into the aggregate for
announcement to its neighbors.
3) A list of neighbor AS's to whom the aggregate will be announced
by the source AS.
4) Contact information, eg. e-mail address and name or NIC handle
of the administrative and technical contacts for the source AS.
Thus, a given aggregate is only listed once in the table by the
source AS.
Expiration Date September 1993 [Page 5]
RFC DRAFT March 1993
Note that this registry reflects both the simple list of aggregates
that are supported by the union of network providers, as well as
providing information on inter-domain topology for the Internet.
Merit will implement procedures for aggregates handled by the NSFNET
to be registered here as well as procedures for updating the
information when routing announcements change. Requests to update the
information will be handled by e-mail to a staff mailing list at
Merit.
4.0 Conclusions and Next Steps
Implementation of CIDR is underway, and there is still a fair amount
of planning and discussion that is needed for a successful
transition. Merit is proposing specific functions for CIDR
aggregation that will be supported by the NSFNET, as well as an
Aggregate Registry that can serve as the basis for inter-domain
routing coordination for CIDR.
Once this paper is discussed, Merit and ANS will make a specific
description of CIDR functionality in the NSFNET service and ANS
backbone available. The policies and administrative procedures as
well as the technical capabilities of the backbone need to be
defined.
The Aggregate Registry will allow a set of tools to be developed that
can facilitate the design of aggregation policy. A query tool to
allow lookup of aggregation information for a given network or
aggregate would be very useful. It will also be possible to undertake
to write an inter-domain topology mapping program based on the source
and destination AS announcements stored in the Registry.
References
[1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an
Address Assignment and Aggregation Strategy', RFC1338, June 1992.
Update, Work in Progress.
[2] BGP-4 protocol
[3] Topolcic CIDR meeting
[4] J. Yu, E. Chen, Y. Rekhter, "Routing Policy Description and
Sharing",
Expiration Date September 1993 [Page 6]
RFC DRAFT March 1993
Work In Progress, March 1993.
[5] Gerich, E., `Guidelines for Management of IP Address Space',
RFC1366, October 1992. Update, Work in Progress.
[6] Rekhter, Li RFC on Net Allocation Guidelines
Expiration Date September 1993 [Page 7]
