idnits 2.17.1 draft-templin-iron-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 04, 2010) is 5192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-01 == Outdated reference: A later version (-05) exists of draft-russert-rangers-01 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-08 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Phantom Works 4 Intended status: Informational February 04, 2010 5 Expires: August 8, 2010 7 The Internet Routing Overlay Network (IRON) 8 draft-templin-iron-00.txt 10 Abstract 12 RANGER examines recursive arrangements of enterprise networks, where 13 the term "enterprise" can apply to a very broad set of use case 14 scenarios. RANGER considers the global Internet itself as the 15 highest level of enterprise network recursion, and assumes that 16 existing policies and operational practices in the current Internet 17 BGP routing system will continue into the foreseeable future. 18 However, RANGER also seeks to arrest the growth of the BGP RIB so 19 that it will level off and not continue to expand along super-linear 20 rates. In particular, RANGER expects that the current Internet BGP 21 routing system will continue to maintain the current RLOC-based RIB, 22 but that future growth due to mobility, multihoming and PI addressing 23 will be increasingly accommodated using EID addressing instead of 24 RLOC addressing. This new growth must be accommodated within 25 acceptable scaling limitations for both the RIB and FIB sizes for 26 EID-based routers in the Internet. Therefore, RANGER proposes that 27 an Internet Routing Overlay Network (IRON) be established over the 28 existing DFZ for the purpose of supporting scalable EID space 29 routing. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on August 8, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. The Internet Routing Overlay Network (IRON) . . . . . . . . . . 3 74 4. Related Initiatives . . . . . . . . . . . . . . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 RANGER [I-D.templin-ranger] examines recursive arrangements of 86 enterprise networks, where the term "enterprise" can apply to a very 87 broad set of use case scenarios [I-D.russert-rangers]. RANGER 88 considers the global Internet itself as the highest level of 89 enterprise network recursion, and assumes that existing policies and 90 operational practices in the current Internet BGP routing system 91 [RFC4271] will continue into the forseeable future. However, RANGER 92 also seeks to arrest the growth of the BGP RIB so that it will level 93 off and not continue to expand along super-linear rates. In 94 particular, RANGER expects that the current Internet BGP routing 95 system will continue to maintain the current RLOC-based RIB, but that 96 future growth due to mobility, multihoming and PI addressing will be 97 increasingly accommodated using EID addressing instead of RLOC 98 addressing. This new growth must be accommodated within acceptable 99 scaling limitations for both the RIB and FIB sizes for EID-based 100 routers in the Internet. Therefore, RANGER proposes that an Internet 101 Routing Overlay Network (IRON) be established over the existing DFZ 102 for the purpose of supporting scalable EID space routing. 104 2. Terminology 106 The terminology of RANGER[I-D.templin-ranger], VET 107 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal] applies 108 also to IRON. 110 IRON observes the Internet Protocol standards [RFC0791][RFC2460]. 112 3. The Internet Routing Overlay Network (IRON) 114 The Internet Routing Overlay Network (IRON) consists of routers that 115 communicate via tunnels across the existing Internet DFZ for the 116 purpose of propagating EID-based routing information and forwarding 117 EID-addressed data packets. Each such IRON router views the global 118 Internet DFZ as a monolithic VET NBMA link, and connects to the link 119 via a VET interface used for automatic tunneling. Each IRON router 120 therefore sees all other IRON routers as single-hop neighbors on the 121 VET link from the standpoint of the inner IP protocol, while they may 122 be separated by many outer IP hops across the underlying RLOC-based 123 Internet. 125 Each IRON router participates in a new IRON-specific BGP instance 126 that carries only EID prefixes and is maintained as a separate BGP 127 instance that does not interact with the current RLOC-based Internet 128 BGP system. Each IRON router sets up IRON BGP peering arrangements 129 with only a limited set of neighbors that are "nearby" within the 130 underlying RLOC-based Internet topology (i.e., it does not establish 131 a full mesh with all other IRON routers). IRON routers can discover 132 the addresses of nearby neighboring IRON routers through static 133 address configuration, resolving a well-known DNS FQDN, or through a 134 limited-scope multicast flood search discovery. When an FQDN is 135 used, each FQDN uses the well-known suffix "isatap.net". 137 IRON routers connect RANGER networks (e.g., ISP networks, large 138 corporate enterprise networks, academic campus networks, etc.) to the 139 IRON, and forward data and control packets between one another via 140 VET automatic tunneling. These IRON routers participate in the IRON 141 BGP instance, however there is no requirement that they also 142 participate in the current Internet RLOC-based BGP routing instance. 143 Therefore, IRON routers can be deployed incrementally and without 144 disturbing the existing Internet routing system. 146 <<< Insert figure 1 here showing example IRON topology >>> 148 The IRON RIB carries only a relatively small number of highly- 149 aggregated EID prefixes that are in some ways similar to the Virtual 150 Prefixes (VPs) proposed for Virtual Aggregation (VA) 151 [I-D.ietf-grow-va], where each VP is "owned" by one or more IRON 152 routers. In particular, the IRON RIB carries only highly-aggregated 153 VPs (e.g., 4000::/8, 4100::/8, etc.) such that the number of VPs 154 carried in the IRON RIB will be kept to a manageable size. The full 155 IRON RIB is propagated to all IRON routers via their peering 156 arrangements, and each IRON router installs all IRON RIB VPs (along 157 with their associated neighboring IRON router nexthop addresses) in 158 its FIB. 160 Customer Edge (CE) routers within RANGER networks will have incentive 161 to use EID-based PI prefixes in order to support mobility and 162 multihoming. Each such CE router "registers" its PI prefixes both 163 within the RANGER network and with any IRON BGP routers that own the 164 VP from which the PI prefix is derived. In particular, CE routers 165 that are holders of PI prefixes "blow bubbles" by sending periodic RA 166 messages that are propagated up through the RANGER network recursive 167 hierarchy. These RA "bubbles" percolate up through a reverse tree 168 ascending through the RANGER network until they reach IRON routers 169 that connect the RANGER network to the IRON. These IRON routers then 170 forwards the RA "bubbles" to any IRON routers that own a VP from 171 which the PI prefix is derived. 173 Once "registered", the CE router's PI prefix are kept only in the 174 FIBs of routers on paths over which the RA "bubbles" travel; the PI 175 prefixes are not injected into the IRON RIB. Moreover, only those 176 routers on the paths over which the CE's EID addressed packets will 177 travel need to install the PI prefix in their FIBs - no other routers 178 need to install the prefixes. The location of the CE router's EID 179 prefixes are tracked through the FIB entries in IRON routers that 180 hold the VPs from which the EID prefixes are derived. Once these VP 181 and more-specific prefix FIB entries are established, end-to-end data 182 communications using RANGER and EID-based addressing is enabled. 183 Data communications are propagated based on available information in 184 router FIBs, where standard longest-prefix-match forwarding is used. 185 However, since the FIB entries of most routers will be sparsely 186 populated, the RANGER mechanisms for data driven route optimization 187 are used. 189 <<< Insert figure 2 here showing RIB; FIB entries of IRON routers >>> 191 As a specific example, when a customer device associated with CE 192 router 'A' needs to send a packet to a customer device associated 193 with CE router 'E' (and the two CE routers are located in different 194 RANGER networks) the packet traverses default routes within the 195 RANGER network recursive hierarchy until it arrives at IRON router 196 'B'. IRON router 'B' then consults its FIB and discovers a VP that 197 covers the 'E' prefix, then forwards the packet via VET automatic 198 tunneling to an IRON router 'C' that owns the VP. Next, if 'E' is 199 "away from home", 'C' consults its FIB and discovers a more-specific 200 route that covers the 'E' prefix. 'C' then forwards the packet to an 201 IRON router 'D' which connects the RANGER network where 'E' currently 202 resides. At the same time, 'C' sends a redirect message to inform 203 'B' of a better nexthop. Thereafter, 'B' will forward packets 204 destined to 'E' directly to 'D' without having to involve 'C', since 205 'B' will have a more-specific route in its FIB. These FIB entries 206 will be maintained as long as data packets are flowing, and allowed 207 to expire when the flow of data packets ceases. 209 <<< Insert figure 3 here showing message exchange example >>> 211 In summary, the RANGER approach to scalable routing within the 212 Internet is to create a new Internet Routing Overlay Network (IRON) 213 using an EID-based BGP instance for the purpose of keeping a limited 214 set of highly-aggregated EID VPs in the RIB. EID prefixes owned by 215 CE routers are added to selected router FIB tables on-demand, and are 216 never injected into the RIB, therefore the FIB sizes of most routers 217 are also reduced. This same hybrid approach using both dynamic 218 routing protocols and on-demand data driven updates applies not only 219 within the IRON DFZ core, but also at any level within a RANGER 220 network recursive hierarchy. 222 4. Related Initiatives 224 IRON builds directly upon the RANGER architecture 225 [I-D.templin-ranger], and therefore inherits the same set of related 226 initiatives. 228 5. IANA Considerations 230 There are no IANA considerations for this document. 232 6. Security Considerations 234 Security considerations for RANGER apply also to IRON. 236 7. Acknowledgements 238 This ideas behind this work have evolved directly from the 239 development of RANGER, VET and SEAL. Discussions with colleagues 240 have helped motivate the work. 242 8. References 244 8.1. Normative References 246 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 247 September 1981. 249 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 250 (IPv6) Specification", RFC 2460, December 1998. 252 8.2. Informative References 254 [I-D.ietf-grow-va] 255 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 256 L. Zhang, "FIB Suppression with Virtual Aggregation", 257 draft-ietf-grow-va-01 (work in progress), October 2009. 259 [I-D.russert-rangers] 260 Russert, S., Fleischman, E., and F. Templin, "RANGER 261 Scenarios", draft-russert-rangers-01 (work in progress), 262 September 2009. 264 [I-D.templin-intarea-seal] 265 Templin, F., "The Subnetwork Encapsulation and Adaptation 266 Layer (SEAL)", draft-templin-intarea-seal-08 (work in 267 progress), January 2010. 269 [I-D.templin-intarea-vet] 270 Templin, F., "Virtual Enterprise Traversal (VET)", 271 draft-templin-intarea-vet-08 (work in progress), 272 January 2010. 274 [I-D.templin-ranger] 275 Templin, F., "Routing and Addressing in Next-Generation 276 EnteRprises (RANGER)", draft-templin-ranger-09 (work in 277 progress), October 2009. 279 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 280 Protocol 4 (BGP-4)", RFC 4271, January 2006. 282 Author's Address 284 Fred L. Templin (editor) 285 Boeing Phantom Works 286 P.O. Box 3707 MC 7L-49 287 Seattle, WA 98124 288 USA 290 Email: fltemplin@acm.org