summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6769.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6769.txt')
-rw-r--r--doc/rfc/rfc6769.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6769.txt b/doc/rfc/rfc6769.txt
new file mode 100644
index 0000000..5c2949c
--- /dev/null
+++ b/doc/rfc/rfc6769.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Raszuk
+Request for Comments: 6769 NTT MCL
+Category: Informational J. Heitz
+ISSN: 2070-1721 Ericsson
+ A. Lo
+ Arista
+ L. Zhang
+ UCLA
+ X. Xu
+ Huawei
+ October 2012
+
+
+ Simple Virtual Aggregation (S-VA)
+
+Abstract
+
+ All BGP routers in the Default-Free Zone (DFZ) are required to carry
+ all routes in the Default-Free Routing Table (DFRT). This document
+ describes a technique, Simple Virtual Aggregation (S-VA), that allows
+ some BGP routers not to install all of those routes into the
+ Forwarding Information Base (FIB).
+
+ Some routers in an Autonomous System (AS) announce an aggregate (the
+ VA prefix) in addition to the routes they already announce. This
+ enables other routers not to install the routes covered by the VA
+ prefix into the FIB as long as those routes have the same next-hop as
+ the VA prefix.
+
+ The VA prefixes that are announced within an AS are not announced to
+ any other AS. The described functionality is of very low operational
+ complexity, as it proposes a confined BGP speaker solution without
+ any dependency on network-wide configuration or requirement for any
+ form of intra-domain tunneling.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+
+
+
+
+Raszuk, et al. Informational [Page 1]
+
+RFC 6769 S-VA October 2012
+
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6769.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Scope of This Document .....................................3
+ 1.2. Requirements Notation ......................................3
+ 1.3. Terminology ................................................3
+ 2. Operation of S-VA ...............................................4
+ 3. Deployment Considerations .......................................6
+ 4. Security Considerations .........................................7
+ 5. Acknowledgements ................................................7
+ 6. Normative References ............................................7
+ 7. Informative References ..........................................7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raszuk, et al. Informational [Page 2]
+
+RFC 6769 S-VA October 2012
+
+
+1. Introduction
+
+ This document describes a technique called Simple Virtual Aggregation
+ (S-VA). It allows some routers not to store some routes in the
+ Forwarding Information Base (FIB) while still advertising and
+ receiving the full Default-Free Routing Table (DFRT) in BGP.
+
+ A typical scenario is as follows. Core routers in the ISP maintain
+ the full DFRT in the FIB and Routing Information Base (RIB). Edge
+ routers maintain the full DFRT in the BGP Local RIB (Loc-RIB), but do
+ not install certain routes in the RIB and FIB. Edge routers may
+ install a default route to core routers, to Area Border Routers (ABR)
+ that are installed on the Point of Presence (POP), to core boundary
+ routers, or to Autonomous System Border Routers (ASBRs).
+
+ S-VA must be enabled on an edge router that needs to save its RIB and
+ FIB space. The core routers must announce a new prefix called
+ Virtual Aggregate (VA prefix).
+
+1.1. Scope of This Document
+
+ The VA prefix is not intended to be announced from one AS into
+ another, only between routers of the same AS.
+
+ S-VA can be used for both IPv4 unicast and multicast address families
+ and IPv6 unicast and multicast address families.
+
+ S-VA does not need to operate on every router in an AS.
+
+1.2. Requirements Notation
+
+ 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 [RFC2119].
+
+1.3. Terminology
+
+ RIB/FIB-Installing Router (FIR): A router that does not suppress any
+ routes and announces the VA prefix. Typically, a core router, a
+ POP to core boundary router, or an ASBR would be configured as an
+ FIR.
+
+ RIB/FIB-Suppressing Router (FSR): An S-VA router that installs the
+ VA prefix, but does not install routes that are covered by and
+ have the same next-hop as the VA prefix into its FIB. Typically,
+ an edge router would be configured as an FSR.
+
+
+
+
+
+Raszuk, et al. Informational [Page 3]
+
+RFC 6769 S-VA October 2012
+
+
+ Suppress: Not to install a route that is covered by the VA prefix
+ into the global RIB or FIB.
+
+ Legacy Router: A router that does not run S-VA and has no knowledge
+ of S-VA.
+
+ Global Routing Information Base (RIB): All routing protocols in a
+ router install their selected routes into the RIB. The routes in
+ the RIB are used to resolve next-hops for other routes, to be
+ redistributed to other routing protocols, and to be installed into
+ the FIB.
+
+ Local/Protocol Routing Information Base (Loc-RIB): The Loc-RIB
+ contains the routes that have been selected by the local BGP
+ speaker's Decision Process as in [RFC4271].
+
+ NLRI: Network Layer Reachability Information [RFC4271]
+
+2. Operation of S-VA
+
+ There are three types of routers in S-VA: FIB-Installing routers
+ (FIR), FIB-Suppressing routers (FSR), and, optionally, legacy
+ routers. While any router can be an FIR or an FSR, the simplest form
+ of deployment is for AS border routers to be configured as FIRs and
+ for customer facing edge routers to be configured as FSRs.
+
+ When a FIR announces a VA prefix, it sets the path attributes as
+ follows. The ORIGIN MUST be set to INCOMPLETE (value 2). The
+ NEXT_HOP MUST be set to the same value as that of the routes that are
+ intended to be covered by the VA prefix. The ATOMIC_AGGREGATE and
+ AGGREGATOR attributes SHOULD NOT be included. The FIR MUST attach a
+ NO_EXPORT community attribute [RFC1997]. The NLRI SHOULD be 0/0.
+
+ A FIR SHOULD NOT FIB-suppress any routes.
+
+ An FSR must detect the VA prefix or prefixes (including 0/0) and
+ install them in all of Loc-RIB, RIB, and FIB. The FSR MAY suppress
+ any more-specific routes that carry the same next-hop as the VA
+ prefix.
+
+ Generally, any more-specific route that carries the same next-hop as
+ the VA prefix is eligible for suppression. However, provided that
+ there is at least one less-specific prefix with a different next-hop
+ between the VA prefix and the suppressed prefixes, then those
+ suppressed prefixes must be reinstalled.
+
+ An example with three prefixes can be considered where the VA-prefix
+ (prefix 1) is the least specific and covers prefix 2 and prefix 3.
+
+
+
+Raszuk, et al. Informational [Page 4]
+
+RFC 6769 S-VA October 2012
+
+
+ Prefix 2 is less specific than prefix 3 and covers the latter. If
+ all three have the same next-hop, then only the bigger one, i.e.,
+ VA-Prefix, is announced. However, if prefix 2 has a different
+ next-hop, then it will need to be announced separately. In this
+ case, it is important to also announce prefix 3 separately.
+
+ Similarly, when Internal BGP (IBGP) multipath is enabled, and when
+ multiple VA prefixes form a multipath, only those more-specific
+ prefixes of which the set of next-hops are identical to the set of
+ next-hops of the VA prefix multipath are subject to suppression.
+
+ The expected behavior is illustrated in Figure 1. This figure shows
+ an AS with a FIR, FIR1, and an FSR, FSR1. FSR1 is an ASBR and is
+ connected to two external ASBRs, EP1 and EP2.
+
+ +------------------------------------------+
+ | Autonomous System | +----+
+ | | |EP1 |
+ | /---+---| |
+ | To ----\ +----+ +----+ / | +----+
+ | Other \|FIR1|----------|FSR1|/ |
+ |Routers /| | | |\ |
+ | ----/ +----+ +----+ \ | +----+
+ | \---+---|EP2 |
+ | | | |
+ | | +----+
+ +------------------------------------------+
+
+ Figure 1
+
+ Suppose that FSR1 has been enabled to perform S-VA. Originally, it
+ receives all routes from FIR1 (doing next-hop-self) as well as from
+ EP1 and EP2. FIR1 now will advertise a VA prefix 0/0 with the next-
+ hop set to itself. This will cause FSR1 to suppress all routes with
+ the same next-hop as the VA prefix. However, FSR1 will not suppress
+ any routes received from EP1 and EP2, because their next-hops are
+ different from that of the VA prefix.
+
+ Several FIRs may announce different S-VA prefixes. For example, in a
+ POP, each edge router can announce into the POP an S-VA prefix that
+ covers the addresses of the customers it services.
+
+ Several FIRs may announce the same S-VA prefix. In this case, an FSR
+ must choose to install only one of them. For example, two redundant
+ ASBRs, both of which announce the complete DFRT, may each also
+ announce the default route as an S-VA prefix into the AS.
+
+
+
+
+
+Raszuk, et al. Informational [Page 5]
+
+RFC 6769 S-VA October 2012
+
+
+ S-VA may be used to split traffic among redundant exit routers. For
+ example, suppose in Figure 1 that EP1 and EP2 are two redundant ASBRs
+ that announce the complete DFRT. Each may also announce two S-VA
+ prefixes into the AS: 0/1 and 128/1. EP1 might announce 0/1 with
+ higher preference and EP2 might announce 128/1 with higher
+ preference. FIR1 will now install into its FIB 0/1 pointing to EP1
+ and 128/1 pointing to EP2. If either EP1 or EP2 were to fail, then
+ FSR1 would switch the traffic to the other exit router with a single
+ FIB installation of one S-VA prefix.
+
+3. Deployment Considerations
+
+ BGP routes may be used to resolve next-hops for static routes or
+ other BGP routes. Because the default route does not imply
+ reachability of any destination, a router can be configured to not
+ resolve next-hops using the default route. In this case, S-VA should
+ not suppress a route that may be used to resolve a next-hop for
+ another route from installation into the RIB. It may still suppress
+ it from installation into the FIB.
+
+ Selected BGP routes in the RIB may be redistributed to other
+ protocols. If they no longer exist in the RIB, they will not be
+ redistributed. This is especially important when the conditional
+ redistribution is taking place based on the length of the prefix,
+ community value, etc. In those cases where a redistribution policy
+ is in place, S-VA implementation should refrain from suppressing
+ installation into the RIB routes matching such policy. It may still
+ suppress them from installation into the FIB.
+
+ A router may originate a network route or an aggregate route into
+ BGP. Some addresses covered by such a route may not exist. If this
+ router were to receive a packet for an unreachable address within an
+ originated route, it must not send that packet to the VA prefix
+ route. There are several ways to achieve this. One way is to have
+ the FIR aggregate the routes instead of the FSR. Another way is to
+ install a black hole route for the nonexistent addresses on the
+ originating router. This issue is not specific to S-VA, but
+ applicable to the general use of default routes.
+
+ Like any aggregate, an S-VA prefix may include more address space
+ than the sum of the prefixes it covers. As such, the S-VA prefix may
+ provide a route for a packet for which no real destination exists.
+ An FSR will forward such a packet to the FIR.
+
+ If an S-VA prefix changes its next-hop or is removed, then many
+ routes may need to be downloaded into the FIB to achieve convergence.
+
+
+
+
+
+Raszuk, et al. Informational [Page 6]
+
+RFC 6769 S-VA October 2012
+
+
+4. Security Considerations
+
+ The authors are not aware of any new security considerations due to
+ S-VA. The local nature of the proposed optimization eliminates any
+ external exposure of the functionality. The presence of more
+ specifics that are used as VA prefixes is also a normal BGP behavior
+ in current networks.
+
+5. Acknowledgements
+
+ The concept for Virtual Aggregation comes from Paul Francis. In this
+ document, the authors only simplified some aspects of its behavior to
+ allow simpler adoption by some operators.
+
+ The authors would like to thank Clarence Filsfils, Nick Hilliard, S.
+ Moonesamy, and Tom Petch for their review and valuable input.
+
+6. Normative References
+
+ [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
+ Attribute", RFC 1997, August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
+ Pignataro, "The Generalized TTL Security Mechanism
+ (GTSM)", RFC 5082, October 2007.
+
+7. Informative References
+
+ [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+ Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+ 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raszuk, et al. Informational [Page 7]
+
+RFC 6769 S-VA October 2012
+
+
+Authors' Addresses
+
+ Robert Raszuk
+ NTT MCL
+ 101 S Ellsworth Avenue Suite 350
+ San Mateo, CA 94401
+ USA
+
+ EMail: robert@raszuk.net
+
+
+ Jakob Heitz
+ Ericsson
+ 300 Holger Way
+ San Jose, CA 95134
+ USA
+
+ EMail: jakob.heitz@ericsson.com
+
+
+ Alton Lo
+ Arista Networks
+ 5470 Great America Parkway
+ Santa Clara, CA 95054
+ USA
+
+ EMail: altonlo@aristanetworks.com
+
+
+ Lixia Zhang
+ UCLA
+ 3713 Boelter Hall
+ Los Angeles, CA 90095
+ USA
+
+ EMail: lixia@cs.ucla.edu
+
+
+ Xiaohu Xu
+ Huawei Technologies
+ Huawei Building, No.3 Xinxi Rd.,
+ Shang-Di Information Industry Base, Hai-Dian District
+ Beijing 100085
+ P.R. China
+
+ Phone: +86 10 82836073
+ EMail: xuxh@huawei.com
+
+
+
+
+Raszuk, et al. Informational [Page 8]
+