Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational February 04, 2010 Expires: August 8, 2010 The Internet Routing Overlay Network (IRON) draft-templin-iron-00.txt Abstract RANGER examines recursive arrangements of enterprise networks, where the term "enterprise" can apply to a very broad set of use case scenarios. RANGER considers the global Internet itself as the highest level of enterprise network recursion, and assumes that existing policies and operational practices in the current Internet BGP routing system will continue into the foreseeable future. However, RANGER also seeks to arrest the growth of the BGP RIB so that it will level off and not continue to expand along super-linear rates. In particular, RANGER expects that the current Internet BGP routing system will continue to maintain the current RLOC-based RIB, but that future growth due to mobility, multihoming and PI addressing will be increasingly accommodated using EID addressing instead of RLOC addressing. This new growth must be accommodated within acceptable scaling limitations for both the RIB and FIB sizes for EID-based routers in the Internet. Therefore, RANGER proposes that an Internet Routing Overlay Network (IRON) be established over the existing DFZ for the purpose of supporting scalable EID space routing. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. Templin Expires August 8, 2010 [Page 1] Internet-Draft IRON February 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 8, 2010. Copyright Notice Copyright (c) 2010 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 BSD License. Templin Expires August 8, 2010 [Page 2] Internet-Draft IRON February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Internet Routing Overlay Network (IRON) . . . . . . . . . . 3 4. Related Initiatives . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Templin Expires August 8, 2010 [Page 3] Internet-Draft IRON February 2010 1. Introduction RANGER [I-D.templin-ranger] examines recursive arrangements of enterprise networks, where the term "enterprise" can apply to a very broad set of use case scenarios [I-D.russert-rangers]. RANGER considers the global Internet itself as the highest level of enterprise network recursion, and assumes that existing policies and operational practices in the current Internet BGP routing system [RFC4271] will continue into the forseeable future. However, RANGER also seeks to arrest the growth of the BGP RIB so that it will level off and not continue to expand along super-linear rates. In particular, RANGER expects that the current Internet BGP routing system will continue to maintain the current RLOC-based RIB, but that future growth due to mobility, multihoming and PI addressing will be increasingly accommodated using EID addressing instead of RLOC addressing. This new growth must be accommodated within acceptable scaling limitations for both the RIB and FIB sizes for EID-based routers in the Internet. Therefore, RANGER proposes that an Internet Routing Overlay Network (IRON) be established over the existing DFZ for the purpose of supporting scalable EID space routing. 2. Terminology The terminology of RANGER[I-D.templin-ranger], VET [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal] applies also to IRON. IRON observes the Internet Protocol standards [RFC0791][RFC2460]. 3. The Internet Routing Overlay Network (IRON) The Internet Routing Overlay Network (IRON) consists of routers that communicate via tunnels across the existing Internet DFZ for the purpose of propagating EID-based routing information and forwarding EID-addressed data packets. Each such IRON router views the global Internet DFZ as a monolithic VET NBMA link, and connects to the link via a VET interface used for automatic tunneling. Each IRON router therefore sees all other IRON routers as single-hop neighbors on the VET link from the standpoint of the inner IP protocol, while they may be separated by many outer IP hops across the underlying RLOC-based Internet. Each IRON router participates in a new IRON-specific BGP instance that carries only EID prefixes and is maintained as a separate BGP instance that does not interact with the current RLOC-based Internet BGP system. Each IRON router sets up IRON BGP peering arrangements Templin Expires August 8, 2010 [Page 4] Internet-Draft IRON February 2010 with only a limited set of neighbors that are "nearby" within the underlying RLOC-based Internet topology (i.e., it does not establish a full mesh with all other IRON routers). IRON routers can discover the addresses of nearby neighboring IRON routers through static address configuration, resolving a well-known DNS FQDN, or through a limited-scope multicast flood search discovery. When an FQDN is used, each FQDN uses the well-known suffix "isatap.net". IRON routers connect RANGER networks (e.g., ISP networks, large corporate enterprise networks, academic campus networks, etc.) to the IRON, and forward data and control packets between one another via VET automatic tunneling. These IRON routers participate in the IRON BGP instance, however there is no requirement that they also participate in the current Internet RLOC-based BGP routing instance. Therefore, IRON routers can be deployed incrementally and without disturbing the existing Internet routing system. <<< Insert figure 1 here showing example IRON topology >>> The IRON RIB carries only a relatively small number of highly- aggregated EID prefixes that are in some ways similar to the Virtual Prefixes (VPs) proposed for Virtual Aggregation (VA) [I-D.ietf-grow-va], where each VP is "owned" by one or more IRON routers. In particular, the IRON RIB carries only highly-aggregated VPs (e.g., 4000::/8, 4100::/8, etc.) such that the number of VPs carried in the IRON RIB will be kept to a manageable size. The full IRON RIB is propagated to all IRON routers via their peering arrangements, and each IRON router installs all IRON RIB VPs (along with their associated neighboring IRON router nexthop addresses) in its FIB. Customer Edge (CE) routers within RANGER networks will have incentive to use EID-based PI prefixes in order to support mobility and multihoming. Each such CE router "registers" its PI prefixes both within the RANGER network and with any IRON BGP routers that own the VP from which the PI prefix is derived. In particular, CE routers that are holders of PI prefixes "blow bubbles" by sending periodic RA messages that are propagated up through the RANGER network recursive hierarchy. These RA "bubbles" percolate up through a reverse tree ascending through the RANGER network until they reach IRON routers that connect the RANGER network to the IRON. These IRON routers then forwards the RA "bubbles" to any IRON routers that own a VP from which the PI prefix is derived. Once "registered", the CE router's PI prefix are kept only in the FIBs of routers on paths over which the RA "bubbles" travel; the PI prefixes are not injected into the IRON RIB. Moreover, only those routers on the paths over which the CE's EID addressed packets will Templin Expires August 8, 2010 [Page 5] Internet-Draft IRON February 2010 travel need to install the PI prefix in their FIBs - no other routers need to install the prefixes. The location of the CE router's EID prefixes are tracked through the FIB entries in IRON routers that hold the VPs from which the EID prefixes are derived. Once these VP and more-specific prefix FIB entries are established, end-to-end data communications using RANGER and EID-based addressing is enabled. Data communications are propagated based on available information in router FIBs, where standard longest-prefix-match forwarding is used. However, since the FIB entries of most routers will be sparsely populated, the RANGER mechanisms for data driven route optimization are used. <<< Insert figure 2 here showing RIB; FIB entries of IRON routers >>> As a specific example, when a customer device associated with CE router 'A' needs to send a packet to a customer device associated with CE router 'E' (and the two CE routers are located in different RANGER networks) the packet traverses default routes within the RANGER network recursive hierarchy until it arrives at IRON router 'B'. IRON router 'B' then consults its FIB and discovers a VP that covers the 'E' prefix, then forwards the packet via VET automatic tunneling to an IRON router 'C' that owns the VP. Next, if 'E' is "away from home", 'C' consults its FIB and discovers a more-specific route that covers the 'E' prefix. 'C' then forwards the packet to an IRON router 'D' which connects the RANGER network where 'E' currently resides. At the same time, 'C' sends a redirect message to inform 'B' of a better nexthop. Thereafter, 'B' will forward packets destined to 'E' directly to 'D' without having to involve 'C', since 'B' will have a more-specific route in its FIB. These FIB entries will be maintained as long as data packets are flowing, and allowed to expire when the flow of data packets ceases. <<< Insert figure 3 here showing message exchange example >>> In summary, the RANGER approach to scalable routing within the Internet is to create a new Internet Routing Overlay Network (IRON) using an EID-based BGP instance for the purpose of keeping a limited set of highly-aggregated EID VPs in the RIB. EID prefixes owned by CE routers are added to selected router FIB tables on-demand, and are never injected into the RIB, therefore the FIB sizes of most routers are also reduced. This same hybrid approach using both dynamic routing protocols and on-demand data driven updates applies not only within the IRON DFZ core, but also at any level within a RANGER network recursive hierarchy. Templin Expires August 8, 2010 [Page 6] Internet-Draft IRON February 2010 4. Related Initiatives IRON builds directly upon the RANGER architecture [I-D.templin-ranger], and therefore inherits the same set of related initiatives. 5. IANA Considerations There are no IANA considerations for this document. 6. Security Considerations Security considerations for RANGER apply also to IRON. 7. Acknowledgements This ideas behind this work have evolved directly from the development of RANGER, VET and SEAL. Discussions with colleagues have helped motivate the work. 8. References 8.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 8.2. Informative References [I-D.ietf-grow-va] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", draft-ietf-grow-va-01 (work in progress), October 2009. [I-D.russert-rangers] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", draft-russert-rangers-01 (work in progress), September 2009. [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Templin Expires August 8, 2010 [Page 7] Internet-Draft IRON February 2010 Layer (SEAL)", draft-templin-intarea-seal-08 (work in progress), January 2010. [I-D.templin-intarea-vet] Templin, F., "Virtual Enterprise Traversal (VET)", draft-templin-intarea-vet-08 (work in progress), January 2010. [I-D.templin-ranger] Templin, F., "Routing and Addressing in Next-Generation EnteRprises (RANGER)", draft-templin-ranger-09 (work in progress), October 2009. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. Author's Address Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires August 8, 2010 [Page 8]