a crude method of limiting long-prefix propagation
abha
ahuja at wibh.net
Fri Mar 23 08:47:13 UTC 2001
Very cool. This is very similar to what I had in mind from my discussions
with folks earlier this week. Although I've only skimmed the draft at
this point, it seems that this is for the case when the aggregate and the
more specifics are announced. It would be interesting to consider
applying this mechanism for cases where only the more specifics are
heard... meaning, specifying when it would be safe to aggregate two or
more specific announcements.
-abha ;)
On Fri, 23 Mar 2001, Joe Abley wrote:
> On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote:
> > With a small change in semantics, it seems like this scheme is sufficient to
> > support restricted announcement of any route to an explicit set of ASes. Just
> > change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable
> > to', so that a participating AS will only advertise this route to a peer if
> > the proper community attribute appears in the route.
>
> Yup. I already piped the -00 draft through asp and derived something
> very similar. The following draft does not contain the one-AS-hop
> limitation, and includes sample config for IOS and JUNOS.
>
> http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control-01.txt
>
> As suggested by Curtis, Ben is plugging the basic idea encompassed in
> this mechanism into a new bgp attribute, as an alternative approach to
> using community strings.
>
>
> Joe
>
>
> Network Working Group J. Abley
> Internet-Draft Metromedia Fiber Network Inc.
> Expires: September 21, 2001 March 23, 2001
>
>
> Edge Policy Propagation Control
> draft-jabley-edge-policy-propagation-control-01
>
> 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 21, 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 21, 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 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 21, 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 21, 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 fine-grain policy. Aggregate prefixes are advertised as
> normal; long prefixes are advertised tagged with community attributes
> which define their scope:
>
> EPPC_ALLOW:0 -- this prefix should be handled according to the
> convention described in this document.
>
> EPPC_ALLOW:A -- it is desirable that this prefix should propagate to
> AS A. Multiple communities of the form EPPC_ALLOW:A may be
> present to define propagation scope.
>
> 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 additional clauses in
> their advertisement policy to all neighbour ASes, as follows:
>
> o When announcing prefixes to AS A: if the community attributes
> EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the
> EPPC_ALLOW:A community, and then advertise the prefix.
>
> o If the community attribute EPPC_ALLOW:0 is present, and
> EPPC_ALLOW:A is not present, then suppress the advertisement.
>
> An implementation of this policy for cisco and Juniper routers can be
> found in Section 5.
>
> 3.3 Related Work
>
> A similar approach based on a new BGP attribute is described in the
> companion document draft-black-prop-list-00.txt.
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 2001 [Page 5]
>
> Internet-Draft Edge Policy Propagation Control March 2001
>
>
> 4. Example
>
> Consider the following internetwork:
>
>
> +------+
> +-----+ AS B +-----+
> | +---+--+ |
> +---+--+ | +--+---+ +------+
> | AS A | | | AS D +----+ AS F |
> +---+--+ | +--+---+ +------+
> | +---+--+ |
> +-----+ AS C +-----+
> +---+--+
> |
> +---+--+
> | AS E |
> +------+
>
>
> AS A requires a particular set of prefixes to propagate within AS B,
> D and F, but not elsewhere.
>
> AS A therefore advertises the set of prefixes with the community
> attributes EPPC_ALLOW:0, EPPC_ALLOW:D and EPPC_ALLOW:F.
>
> AS B suppresses the advertisements towards AS C, since the community
> attribute APPC_ALLOW:0 is present without APPC_ALLOW:C. AS B
> advertises the prefixes towards AS D, removing APPC_ALLOW:D before
> sending.
>
> Similarly, AS D suppresses the advertisements towards AS C, and
> advertises the prefixes towards AS F after removing APPC_ALLOW:E.
>
> AS F suppresses the advertisements towards all peers, since
> APPC_ALLOW:0 is present without any other APPC_ALLOW:*.
>
> The result is that the long prefix routes only propagate to AS B, AS
> D and AS F, in accordance with the policy specified by AS A.
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 2001 [Page 6]
>
> Internet-Draft Edge Policy Propagation Control March 2001
>
>
> 5. Sample Implementations
>
> 5.1 Juniper JUNOS
>
>
> policy-options {
> /* EPPC policy towards A. */
> policy-statement eppc-to-A {
> /* If this route is an EPPC route and is for A, then delete
> * EPCC:A and continue.
> */
> term is-A {
> from community [ comm-eppc-zero comm-eppc-A ];
> then {
> community delete comm-eppc-A;
> next policy;
> }
> }
> /* If this route is an EPPC route, then drop it. */
> term is-eppc {
> from community comm-eppc-zero;
> then reject;
> }
> /* Otherwise continue as normal. */
> then next policy
> }
> /* The EPPC:0 community */
> community comm-eppc-zero members EPPC_ALLOW:0;
> /* The EPPC:A community meaning send to AS A */
> community comm-eppc-A members EPPC_ALLOW:A;
> }
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 2001 [Page 7]
>
> Internet-Draft Edge Policy Propagation Control March 2001
>
>
> 5.2 cisco IOS
>
>
> ip community-list EPPC-0 permit EPPC_ALLOW:0
> ip community-list EPPC-200 permit EPPC_ALLOW:200
> !
> route-map AS200 permit 10
> match comm-list EPPC-0 EPPC-200
> set comm-list EPPC-0 delete
> !
> route-map AS200 deny 20
> match comm-list EPPC-0
> !
> route-map AS200 permit 30
> !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 2001 [Page 8]
>
> Internet-Draft Edge Policy Propagation Control March 2001
>
>
> 6. Acknowledgements
>
> Thanks to Andrew Partan for excellent envelope-scribbling and for the
> Juniper config fragment.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Abley Expires September 21, 2001 [Page 9]
>
> 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 21, 2001 [Page 10]
>
> 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 21, 2001 [Page 11]
>
>
More information about the Ptomaine
mailing list