draft-ietf-idr-autosys-guide-01.txt   draft-ietf-idr-autosys-guide-02.txt 
Network Working Group J. Hawkinson Network Working Group J. Hawkinson
INTERNET-DRAFT Panix INTERNET-DRAFT Panix
Category: Informational T. Bates Category: Informational T. Bates
<draft-ietf-idr-autosys-guide-01.txt> MCI <draft-ietf-idr-autosys-guide-02.txt> MCI
January 1995 February 1995
Guidelines for creation, selection, and registration Guidelines for creation, selection, and registration
of an Autonomous System (AS) of an Autonomous System (AS)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 9, line 22 skipping to change at page 9, line 22
sions. Nevertheless, it may occasionally be necessary to split up an sions. Nevertheless, it may occasionally be necessary to split up an
AS or a prefix into two ASes for policy reasons. Those making exter- AS or a prefix into two ASes for policy reasons. Those making exter-
nal policy may request the network operators make such AS changes, nal policy may request the network operators make such AS changes,
but the final decision is up to those network operators who manage but the final decision is up to those network operators who manage
the prefixes in question, as well as the ASes containing them. This the prefixes in question, as well as the ASes containing them. This
is, of course, a trade off -- it will not always be possible to is, of course, a trade off -- it will not always be possible to
implement all desired routing policies. implement all desired routing policies.
7. One prefix, one origin AS 7. One prefix, one origin AS
A prefix can and must belong to only one AS. This is a direct conse- Generally, a prefix can should belong to only one AS. This is a
quence of the fact that at each point in the Internet there can be direct consequence of the fact that at each point in the Internet
exactly one routing policy for traffic destined to each prefix. In there can be exactly one routing policy for traffic destined to each
the case of an prefix which is used in neighbor peering between two prefix. In the case of an prefix which is used in neighbor peering
ASes, a conscious decision must be made as to which AS this prefix between two ASes, a conscious decision should be made as to which AS
actually resides in. this prefix actually resides in.
With the introduction of aggregation it should be noted that an AS With the introduction of aggregation it should be noted that an AS
can occasionally be represented as residing in more than one AS, how- can occasionally be represented as residing in more than one AS, how-
ever, this is very much the exception rather than the rule. This hap- ever, this is very much the exception rather than the rule. This hap-
pens when aggregating using the AS_SET attribute in BGP, wherein the pens when aggregating using the AS_SET attribute in BGP, wherein the
concept of origin is lost. In some cases the origin AS is lost alto- concept of origin is lost. In some cases the origin AS is lost alto-
gether if there is a less specific aggregate announcement setting the gether if there is a less specific aggregate announcement setting the
ATOMIC_AGGREGATE attribute. ATOMIC_AGGREGATE attribute.
8. IGP Issues 8. IGP Issues
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/