a crude method of limiting long-prefix propagation
Joe Abley
jabley-ietf at automagic.org
Fri Mar 23 04:31:56 UTC 2001
http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control-00.txt
This is something that came out of a couple of conversations in the bar.
Hopefully I captured some of the salient points before the vodka kicked
in.
I thought this might qualify as a possible short-term measure to reduce
prefix bloat, hence ptomaine.
Someone set me up the flame.
Network Working Group J. Abley
Internet-Draft Metromedia Fiber Network Inc.
Expires: September 20, 2001 March 22, 2001
Edge Policy Propagation Control
draft-jabley-edge-policy-propagation-control-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
There is a requirement for some multi-homed sites to influence the
path selected by autonomous systems beyond those that are immediately
adjacent.
One of the few generic mechanisms available is to deaggregate and
advertise long component prefixes to the network, since there can be
some confidence that the longest prefix will be used, regardless of
other local policy such as local preference. Most ASes exhibit
liberal route import policy with respect to prefix length, which
facilitates this technique.
Unfortunately, although the deaggregated prefix set may be required
Abley Expires September 20, 2001 [Page 1]
Internet-Draft Edge Policy Propagation Control March 2001
to be installed in only a few targeted ASes for the aims of the
origin to be achieved, there is no reliable mechanism to limit the
propagation of the prefixes. This contributes to prefix bloat in the
default-free zone, which is a concern.
This draft describes a community-based convention which might be used
to limit propagation of long prefixes to those ASes where they are
required to meet the edge policy for cases where the target ASes are
no further than one AS hop away from the transit AS.
Abley Expires September 20, 2001 [Page 2]
Internet-Draft Edge Policy Propagation Control March 2001
1. Introduction
There is a requirement for some multi-homed sites to influence the
path selected by autonomous systems beyond those that are immediately
adjacent.
One of the few generic mechanisms available is to deaggregate and
advertise long component prefixes to the network, since there can be
some confidence that the longest prefix will be used, regardless of
other local policy such as local preference. Most ASes exhibit
liberal route import policy with respect to prefix length, which
facilitates this technique.
Unfortunately, although the deaggregated prefix set may be required
to be installed in only a few targeted ASes for the aims of the
origin to be achieved, there is no reliable mechanism to limit the
propagation of the prefixes. This contributes to prefix bloat in the
default-free zone, which is a concern.
Abley Expires September 20, 2001 [Page 3]
Internet-Draft Edge Policy Propagation Control March 2001
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Abley Expires September 20, 2001 [Page 4]
Internet-Draft Edge Policy Propagation Control March 2001
3. Edge Policy Propagation Convention
3.1 At the Edge
An edge site deaggregates its advertisements according to the
required differential policy. Aggregate prefixes are advertised as
normal; long prefixes are advertised towards particular transit ASes
tagged with community attributes which define their scope:
EPPC_ALOW:ME this prefix should be handled according to the
convention described in this document; ME is the ASN of the first
transit AS.
EPPC_ALLOW:A It is desirable that this prefix should propagate as far
as AS A.
EPPC_ALLOW is some 16-bit quantity, well-known amongst the community
of operators who cooperate according to this convention. It should
be chosen from the private-use range of ASNs specified in [2].
3.2 Towards the Other Edge
ASes which support this convention must include an additional clause
in their advertisement policy to all peer ASes, as follows:
o If the community attribute EPPC_ALLOW:ME is present, and
EPPC_ALLOW:YOU is not present, then AS ME should suppress the
advertisement towards AS YOU.
o If the community attribute EPPC_ALLOW:ME is present, and
EPPC_ALLOW:YOU is also present, then AS ME should advertise the
prefix towards AS YOU with the no-export well-known attribute.
Abley Expires September 20, 2001 [Page 5]
Internet-Draft Edge Policy Propagation Control March 2001
4. Commentary
4.1 Related Work
Many ASes have existing policy which provides this functionality.
However, there is little consistency in the policy knobs available to
customers from different providers. Widespread adoption of a
consistent set of base bells and whistles might result in customers
using them.
4.2 Limitations
This mechanism only allows an edge site to reach one AS further into
the network. The ability to reach further and still be constrained
may also be useful.
However, where the edge AS is motivated by the desire to perform
coarse traffic engineering to prominent ASNs, which participate in a
dense mesh of peering in the DFZ, it is not unreasonable to think
that this approach might be sufficient for a significant number of
edge networks to express their policy.
Abley Expires September 20, 2001 [Page 6]
Internet-Draft Edge Policy Propagation Control March 2001
5. Example
Consider the following internetwork:
+------+
+-----+ AS B +-----+
| +---+--+ |
+---+--+ | +--+---+
| AS A | | | AS D |
+---+--+ | +--+---+
| +---+--+ |
+-----+ AS C +-----+
+---+--+
|
+---+--+
| AS E |
+------+
AS A exchanges a large volume of traffic with AS D, but is unable to
peer with AS D directly. Their policy requirement is that inbound
traffic from AS D should be split between through their connections
to AS B and AS C. The networks operated by AS A are completely
described by the aggregate 172.16.0.0/16.
AS A determines that 172.16.0.0/17 and 172.16.128.0/17 are each
responsible for sinking approximately half the inbound traffic from
AS D. AS A therefore makes the following advertisements:
o To AS B, announce 172.16.0.0/16 with no community string
attributes, and 172.16.0.0/17 with the community attributes
EPPC_ALLOW:B and EPPC_ALLOW:D.
o To AS C, announce 172.16.0.0/16 with no community string
attributes, and 172.16.128.0/17 with the community attributes
EPPC_ALLOW:C and EPPC_ALLOW:D.
AS B and AS C both accept the prefixes advertised to them. They
advertise 172.16.0.0/16 to all peers, but only advertise the longer-
prefix routes to AS D, since EPPC_ALLOW:B identifies the prefix as
directed edge policy, and the only corresponding policy indicator
present is EPPC_ALLOW:D. The long prefixes are advertised to AS D
with the no-export community set, and hence will not propagate beyond
AS D.
The result is that the long prefix routes only propagate as far as AS
D: AS E, for example, receives the aggregate 172.16.0.0/16 only.
Abley Expires September 20, 2001 [Page 7]
Internet-Draft Edge Policy Propagation Control March 2001
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Hawkinson, J. and T. Bates, "Guidelines for creation, selection,
and registration of an Autonomous System (AS)", RFC 1930, March
1996.
[3] Huston, G., "Analyzing the Internet's BGP Routing Table",
January 2001.
Author's Address
Joe Abley
Metromedia Fiber Network Inc.
2204 Pembroke Court
Burlington, ON L7P 3X8
Canada
Phone: +1 905 319 9064
EMail: jabley at mfnx.net
Abley Expires September 20, 2001 [Page 8]
Internet-Draft Edge Policy Propagation Control March 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Abley Expires September 20, 2001 [Page 9]
More information about the Ptomaine
mailing list