idnits 2.17.1 draft-irtf-routing-reqs-groupa-00.txt: ** The Abstract section seems to be numbered -(1431): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1452): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-irtf-routing-reqs-groupa-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-irtf-routing-reqs-groupa-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-irtf-routing-reqs-groupa-', but the file name used is 'draft-irtf-routing-reqs-groupa-00' == There are 3 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 97 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 286 has weird spacing: '... do not know ...' == Line 299 has weird spacing: '...illions of pr...' == Line 874 has weird spacing: '... packet based...' == Line 1346 has weird spacing: '... We don't...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 2002) is 8047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-iab-bgparch-01 ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) Summary: 9 errors (**), 1 flaw (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF Routing Research Group F. Kastenholz, 3 Internet Draft (ed) 4 Document April 2002 6 Category: Informational 8 Requirements For a Next Generation 9 Routing and Addressing Architecture 10 < draft-irtf-routing-reqs-groupa-00.txt> 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. Internet-Drafts are draft 21 documents valid for a maximum of six months and may be updated, 22 replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet- Drafts as reference material or 24 to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html. 32 Table of Contents 34 1 Abstract...................................................3 36 2 Conventions used in this document..........................3 38 3 Requirements...............................................4 40 3.1 Architecture..........................................4 42 3.2 Separable Components..................................5 44 3.3 Scalable..............................................6 46 3.4 Lots of Interconnectivity.............................7 48 3.5 Random Structure......................................8 50 3.6 Multi-homing..........................................9 52 3.7 Multi-path............................................9 54 3.8 Convergence..........................................10 56 3.9 Routing System Security..............................12 58 3.10 End Host Security....................................14 60 3.11 Rich Policy..........................................14 62 3.11.1 Routing Information Policies......................14 64 3.11.2 Traffic Control Policies..........................15 66 3.12 Incremental Deployment...............................16 68 3.13 Mobility.............................................16 70 3.14 Address Portability..................................17 72 3.15 Multi-Protocol.......................................17 74 3.16 Abstraction..........................................17 76 3.17 Simplicity...........................................18 78 3.18 Robustness...........................................18 80 3.19 Media Independence...................................19 82 3.20 Stand-alone..........................................19 84 3.21 Safety of Configuration..............................19 86 3.22 Renumbering..........................................19 88 3.23 Multi-prefix.........................................19 90 3.24 Cooperative Anarchy..................................19 92 3.25 Network Layer Protocols and Forwarding Model.........20 94 3.26 Routing Algorithm....................................20 96 3.27 Positive Benefit.....................................20 98 3.28 Administrative Entities and the IGP/EGP Split........20 100 4 Non-Requirements..........................................21 102 4.1 Forwarding Table Optimization........................21 104 4.2 Traffic Engineering..................................21 106 4.3 Multicast............................................22 108 4.4 QOS..................................................22 110 4.5 IP Prefix Aggregation................................22 112 4.6 Perfect Safety.......................................23 114 4.7 Dynamic Load Balancing...............................23 116 4.8 Renumbering of hosts and routers.....................23 118 4.9 Host Mobility........................................23 120 4.10 Clean Slate..........................................24 121 5 Discussion of other Inter-Domain Routing Requirements 123 documents....................................................24 125 5.1 Comments on "Architectural Requirements for Inter-Domain 127 Routing in the Internet"..................................24 129 5.2 Comments on "Future Domain Routing Requirements".....25 131 6 Security Considerations...................................28 133 7 IANA Considerations.......................................28 135 8 References................................................28 137 9 Acknowledgments...........................................28 139 10 Editor's Addresses........................................29 141 1 Abstract 143 This note sets requirements for a new routing and addressing 144 architecture for the Internet. These requirements were 145 developed by the IRTF's Routing Research Group. 147 This draft is the product of Group ~B, which is one of the 148 subgroups in the IRTF-Routing Research Group working on 149 requirements for routing solutions for the future. This 150 document sets out requirements that we believe are important 151 for a future routing architecture and routing protocols. The 152 IRTF Routing Research Group (RRG) does not endorse this set of 153 requirements or any other set of requirements as the one and 154 only set of requirements. 156 The seemingly simple requirement is to "fix routing and 157 addressing". However, in order to "fix" it, we also need to 158 understand how routing and addressing are _actually_ used 159 today. This is not a straightforward task. Service providers 160 and network administrators have many different operational and 161 administrative needs. Quite often, the only tool available to 162 meet those needs is the routing system and they have proven 163 amazingly crafty at using that tool in ways that were never 164 envisioned. Thus, one of the most important steps in 165 developing these requirements has been to learn what the 166 operational community really is doing with the routing system, 167 why they are doing it, and then abstracting those tasks into 168 requirements. 170 2 Conventions used in this document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 173 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described 175 in RFC-2119 [2]. 177 We believe that we have captured the essential requirements for 178 one possible future routing and addressing architecture for the 179 Internet. We do not consider features, functions, or 180 capabilities not described in this note to be critically 181 important for a future routing and addressing architecture and 182 they should be considered optional. A specific architecture 183 MAY include OR exclude them without conflicting with this note. 185 There are many IETF documents that define specific terms. We 186 generally choose not to use these strict, well-crafted, 187 definitions. They were made with the current architecture and 188 protocols in mind. A goal of this work is to foster 189 development of new and different architectures. By using the 190 "old" terms we may inadvertently limit or constrain avenues of 191 enquiry and investigation, possibly preventing consideration of 192 promising architectures. 194 3 Requirements 196 This chapter presents the requirements. 198 The requirements presented in this section are NOT presented in 199 any order. A later version of this note may order the 200 requirements in some kind of priority. 202 3.1 Architecture 204 The new routing and addressing protocols, data structures, and 205 algorithms MUST be developed from a clear, well thought out, 206 documented, architecture. 208 The new routing and addressing system must have an 209 architectural specification which describes all of the routing 210 and addressing elements, their interactions, what functions the 211 system performs, and how it goes about performing them. The 212 architectural specification does not go into issues such as 213 protocol and data structure design. 215 The Architecture SHOULD be agnostic with regard to specific 216 algorithms and protocols. 218 Doing architecture before doing detailed protocol design is 219 good engineering practice. This allows the architecture to be 220 reviewed and commented upon, with changes made as necessary, 221 when it is still easy to do so. Also, by producing an 222 architecture, the eventual users of the protocols (the 223 operations community) will have a better understanding of how 224 the designers of the protocols meant them to be used. 226 3.2 Separable Components 228 The architecture MUST place different functions into separate 229 components. 231 Separating functions, capabilities, and so forth, into 232 individual components, and making each component "stand alone" 233 is generally considered by system architects to be "A Good 234 Thing". It allows individual elements of the system to be 235 designed and tuned to do their jobs "very well". It also 236 allows for piecemeal replacement and upgrading of elements as 237 new technologies and algorithms become available. 239 The architecture MUST have the ability to replace or upgrade 240 existing components, and to add new ones, without disrupting 241 the remaining parts of the system. Operators must be able to 242 roll out these changes and additions incrementally (i.e. no 243 "flag days"). These abilities are needed to allow the 244 architecture to evolve as the Internet changes. 246 The Architecture Specification shall define each of these 247 components, their jobs, and their interactions. 249 Some thoughts to consider along these lines are 251 o Making topology and addressing separate subsystems. This 252 may allow highly optimized topology management and 253 discovery without constraining the addressing structure or 254 physical topology in unacceptable ways. 256 o Separate "fault detection and healing" from basic 257 topology. From Mike O'Dell: 258 "Historically the same machinery is used for both. 259 While attractive for many reasons, the availability of 260 exogenous topology information (i.e., the intended 261 topology) should, it seems, make some tasks easier than 262 the general case of starting with zero knowledge. It 263 certainly helps with recovery in the case of constraint 264 satisfaction. In fact, the intended topology is a 265 powerful way to state certain kinds of policy. 267 o Making policy definition and application a separate 268 subsystem, layered overtop of the others. 270 The architecture should also separate topology. routing and 271 addressing from the application that use those components. 272 This implies that applications such as policy definition, 273 forwarding, and circuit and tunnel management are separate 274 subsystems layered overtop of the basic topology, routing, and 275 addressing systems. 277 3.3 Scalable 279 Scaling is the primary problem facing the routing and 280 addressing architecture today. This problem must be solved and 281 it must be solved for the long term. 283 The Architecture MUST support a large and complex network. 284 Ideally, it will serve our needs for the next 20 years. 285 Unfortunately 286 1. We do not know how big the Internet will grow over that 287 time, and 288 2. The architecture developed from these requirements may 289 change the fundamental structure of the Internet, and 290 therefore its growth patterns. This change makes it 291 difficult to predict future growth patterns of the 292 Internet. 294 As a result, we can't quantify the requirement in any 295 meaningful way. Using today's architectural elements as a 296 mechanism for describing things, we believe that the network 297 could grow to 298 1. Tens of thousands of ASes and 299 2. Tens to hundreds of millions of prefixes during the 300 lifetime of this architecture. 301 These sizes are given as a 'flavor' for how we expect the 302 Internet to grow. We fully believe that any new architecture 303 may eliminate some current architectural elements and introduce 304 new ones. 306 A new routing and addressing architecture designed to a 307 specific network size would be inappropriate. First, the cost 308 of routing calculations is based only in part on the number of 309 AS's or prefixes in the network. The number and locations of 310 the links in the network is also a significant factor. Second, 311 past predictions of Internet growth and topology patterns have 312 proven to be wildly inaccurate so developing an architecture to 313 a specific size goal would at best be shortsighted. 315 Therefore we will not make the scaling requirement based on a 316 specific network size. Instead, the new routing and addressing 317 architecture should have the ability to constrain the increase 318 in load (CPU, memory space and bandwidth, and network 319 bandwidth) on ANY SINGLE ROUTER to be less than these specific 320 functions: 322 1. The computational power and memory sizes required to execute 323 the routing protocol software and to contain the tables must 324 be less than the growth in hardware capabilities described 325 by Moore's Law, which has hardware capabilities doubling 326 every 18 months or so. Other observations indicate that 327 memory sizes double every 2 years or so. 329 2. Network bandwidth and latency are some key constraints on 330 how fast routing protocol updates can be disseminated (and 331 therefore how fast the routing system can adapt to changes). 332 Raw network bandwidth seems to quadruple every 3 years or 333 so. However, it seems that there are some serious physics 334 problems in going faster than 40gbits (OC768). We should 335 not expect raw network link speed to grow much beyond OC768. 336 In addition, for economic reasons, large swathes of the core 337 of the Internet will still operate at lower speeds, possibly 338 as slow as DS3. 340 Furthermore, in some sections of the Internet even lower 341 speed links are found. Corporate access links are often T1, 342 or slower. Low-speed radio links exist. Intra-domain links 343 may be T1 or fractional-T1 (or slower). 345 Therefore, the architecture MUST NOT make assumptions about 346 the bandwidth available. 348 3. The speeds of high-speed RAMS (SRAMs, used for caches and 349 the like) are growing, though slowly. Because of their use 350 in caches and other very specific applications, these RAMs 351 tend to be small, a few megabits, and the size of these RAMs 352 is not increasing very rapidly. 354 On the other hand, the speed of "large" memories (DRAMs) is 355 increasing even slower than that for the high speed RAMS. 356 This is because the development of these RAMs is driven by 357 the PC market, where size is very important, and low speed 358 can be made up for by better caches. 360 Memory access rates should not be expected to increase 361 significantly. 363 The growth in resources available to any one router will 364 eventually slow down. It may even stop. Even so, the network 365 will continue to grow. The routing and addressing architecture 366 must continue to scale in even this extreme condition. We 367 cannot continue to add more computing power to routers forever. 368 Other strategies must be available. Some possible strategies 369 are hierarchy, abstraction, and aggregation of topology 370 information.. 372 3.4 Lots of Interconnectivity 374 The new routing and addressing architecture MUST be able to 375 cope with a high degree of interconnectivity in the Internet. 376 That is, there are large numbers of alternate paths and routes 377 among the various elements. Mechanisms are required to prevent 378 this interconnectivity (and continued growth in 379 interconnectivity) from causing tables, compute time, and 380 routing protocol traffic to grow without bound. The "cost" to 381 the routing system of an increase in complexity MUST be limited 382 in scope; sections of the network that do not see, or do not 383 care about, the complexity ought not pay the cost of that 384 complexity. 386 Over the past several years, the Internet has seen an increase 387 in interconnectivity. Individual end sites (companies, 388 customers, etc), ISPs, exchange points, and so on, all are 389 connecting up to more "other things". Company's multi-home to 390 multiple ISPs, ISPs peer with more ISPs, and so on. These 391 connections are made for many reasons, such as getting more 392 bandwidth, increased reliability and availability, policy, and 393 so on. However, this increased interconnectivity has a price. 394 It leads to more scaling problems as it increases the number of 395 AS paths in the networks. 397 Any new architecture must assume that the Internet will become 398 "meshier". It MUST NOT assume, nor can it dictate, certain 399 patterns or limits on how various elements of the network 400 interconnect. 402 Another facet of this requirement is that there may be multiple 403 valid, loop free, paths available to a destination. When there 404 are multiple valid, loop free, paths available, all such paths 405 MUST be available for forwarding traffic. 407 We wryly note that one of the original design goals of IP was 408 to support a large, heavily interconnected, network, which 409 would be highly survivable (such as in the face of a nuclear 410 war). 412 3.5 Random Structure 414 The routing and addressing architecture MUST NOT make any 415 constraints on or assumptions about the topology or 416 connectedness of the elements comprising the Internet. The 417 routing and addressing architecture MUST NOT presume any 418 particular network structure. The network does not have a 419 "nice" structure. In the past we used to believe that there 420 was this nice "backbone/tier-1/tier-2/end-site" sort of 421 hierarchy. This is not so. Therefore, any new Architecture 422 must not presume any such structure. 424 Some have proposed that a geographic addressing scheme be used, 425 requiring exchange points to be situated within each geographic 426 'region'. There are many reasons why we believe this to be a 427 bad approach, but those arguments are irrelevant. The main 428 issue is that the routing architecture should not presume a 429 specific network structure. 431 3.6 Multi-homing 433 The Architecture MUST provide multi-homing for all elements of 434 the Internet. That is, multihoming of hosts, subnetworks, end- 435 sites, "low-level" ISPs, and backbones (i.e. lots of redundant 436 interconnections) must be supported. Among the reasons to 437 multi-home are reliability, load sharing, and performance 438 tuning. 440 The term "multihoming" may be interpreted in its broadest sense 441 -- one "place" has multiple connections or links to another 442 "place". 444 The architecture MUST NOT limit the number of alternate paths 445 to a multi-homed site. 447 When multi-homing, it MUST be possible to use one, some (more 448 than one but less than all) or all of the available paths to 449 the multi-homed site. The multi-homed site must have the 450 ability to declare which path(s) are used and under what 451 conditions (for example, one path may be declared "primary" and 452 the other "backup" and to be used only when the primary fails). 454 A current problem in the Internet is that multihoming leads to 455 undue increases in the size of the BGP routing tables. The new 456 architecture must support multi-homing without causing undue 457 routing table growth. 459 3.7 Multi-path 461 As a corollary to multi-homing, the Architecture MUST allow for 462 multiple paths from a source to a destination to be active at 463 the same time. These paths need not have the same attributes. 464 Policies are to be used to disseminate the attributes and to 465 classify traffic for the different paths. 467 There must be a rich "language" for use in specifying the rules 468 for classifying the traffic and assigning classes of traffic to 469 different paths (or prohibiting it from certain paths). The 470 rules for classification should allow traffic to be classified 471 based on 472 o IPv6 FlowIDs 473 o TOS byte 474 o Source and/or Destination prefixes 475 o Random selections at some probability 476 o ... 478 A mechanism is needed that allows operators to plan and manage 479 the traffic load on the various paths. To start, this 480 mechanism can be semi-automatic, or even manual. Eventually it 481 ought to become fully automatic. 483 When multi-path forwarding is used, options must be available 484 to preserve packet ordering where appropriate (such as for 485 individual TCP connections). 487 Past experience with dynamic load-balancing and management over 488 multiple paths has been bad. Typically, traffic would 489 oscillate, first all traffic would go over one path, then it 490 would all be 'migrated' to a different path, and then back 491 again. Significant research is needed in this area. 493 3.8 Convergence 495 The speed of convergence (also called the "stabilization time") 496 is the time it takes for a router's routing processes to come 497 up with a new, stable, "solution" (i.e. forwarding information 498 base) after a change someplace in the network. In effect, what 499 happens is that the output of the routing calculations 500 stabilizes -- the Nth iteration of the software produces the 501 same results as the N-1th iteration. 503 The speed of convergence is generally considered to be a 504 function of the number of subnetworks in the network and the 505 amount of connections between those networks. As either number 506 grows, the time it takes to converge increases. 508 In addition, a change can "ripple" back and forth through the 509 system. One change can go through the system, causing some 510 other router to change its advertised connectivity, causing a 511 new change to ripple through. These oscillations can take a 512 while to work their way out of the network. It is also 513 possible that these ripples never die out. In this situation 514 the routing and addressing system is unstable; it never 515 converges. 517 Finally, it is more than likely that the routers comprising the 518 Internet never converge simply because the Internet is so large 519 and complex. Assume it takes S seconds for the routers to 520 stabilize on a solution for any one change to the network. 521 Also assume that changes occur, on average, every C seconds. 522 Because of the size and complexity of the Internet, C is now 523 less than S. Therefore, if a change, C1, occurs at time T, the 524 routing system would stabilize at time T+S, but a new change, 525 C2, will occur at time T+C, which is before T+S. The system 526 will start processing the new change before it's done with the 527 old. 529 This is not to say that all routers are constantly processing 530 changes. The effects of changes are like ripples in a pond. 531 They spread outward from where they occur. Some routers will 532 be processing just C1, others C2, others both C1 and C2, and 533 others neither. 535 We have two separate scopes over which we can set requirements 536 with respect to convergence: 538 1. Single Change 539 In this requirement a single change of any type (link 540 addition or deletion, router failure or restart, etc.) is 541 introduced into a stabilized system. No additional changes 542 are introduced. The system must restabilize within TBDms. 543 This requirement is a fairly abstract one as it would be 544 impossible to test in a real network. 546 2. System-wide 547 Defining a single target for maximum convergence time for 548 the real Internet is absurd. As we mentioned earlier, the 549 Internet is large enough and diverse enough so that it is 550 quite likely that new changes are introduced somewhere 551 before the system fully digests old ones. 553 So, the first requirement here is that there must be 554 mechanisms to limit the scope of any one change's visibility 555 and effects. The number of routers that have to perform 556 calculations in response to a change is kept small, as is 557 the settling time. 559 The second requirement is based on the following assumptions 561 - the scope of a change's visibility and impact can be 562 limited. That is, routers within that scope know of 563 the change and recalculate their tables based on the 564 change. Routers outside of the scope don't see it at 565 all. 567 - Within any scope, S, network changes are constantly 568 occurring and the average inter-change interval is Tc 569 seconds. 571 - There are Rs routers within scope S 573 - A subset of the destinations known to the routers in 574 S, Ds, are impacted by a given change. 576 - We can state that for Z% of the changes, within Y% of 577 Tc seconds after a change, C, X% of the Rs routers 578 have their routes to Ds settled to a useful answer 579 (useful meaning that packets can get to Ds, thought 580 perhaps not by the optimal path -- this allows some 581 'hunting' for the optimal solution) 583 X, Y, Z, ARE TBD 585 This requirement implies that the scopes can be kept 586 relatively small in order to minimize Rs and maximize Tc. 588 The growth rate of the convergence time MUST NOT be related to 589 the growth rate of the Internet as a whole. This implies that 590 the convergence time either 591 1. Not be a function of basic network elements (such as 592 prefixes and links/paths), and/or 593 2. That the Internet be continuously divisible into chunks that 594 limit the scope and effect of a change, thereby limiting the 595 number of routers, prefixes, links, and so on involved in 596 the new calculations. 598 3.9 Routing System Security 600 The security of the Internet's routing system is paramount. If 601 the routing system is compromised or attacked, the entire 602 Internet can fail. This is unacceptable. Any new Architecture 603 must be secure. 605 Architectures by themselves are not secure. It is the 606 implementation of an architecture; its protocols, algorithms, 607 and data structures, that are secure. These requirements apply 608 primarily to the implementation. The architecture MUST provide 609 the elements that the implementation needs to meet these 610 security requirements. Also, the architecture MUST NOT prevent 611 these security requirements from being met. 613 Security means different things to different people. In order 614 for this requirement to be useful, we must define what we mean 615 by security. We do this by identifying the attackers and 616 threats we wish to protect against. They are: 618 Masquerading 619 The system, including its protocols, MUST be secure against 620 intruders adopting the identity of other known, trusted, 621 elements of the routing system and then using that position 622 of trust for carrying out other attacks. Protocols MUST use 623 cryptographically strong authentication. 625 DOS Attacks 626 The architecture and protocols SHOULD be secure against DOS 627 attacks directed at the routers. 629 The new architecture and protocols SHOULD provide as much 630 information as it can to allow administrators to track down 631 sources of DOS and DDOS attacks. 633 No Bad Data 634 Any new architecture and protocols must provide protection 635 against the introduction of bad, bogus, or misleading, data 636 by attackers. Of particular importance, an attacker must 637 not be able to redirect traffic flows, with the intent of 638 o Directing legitimate traffic away from a target, causing 639 a denial-of-service attack by preventing legitimate data 640 from reaching its destination, 641 o Directing additional traffic (going to other 642 destinations which are 'innocent bystanders') to a 643 target, causing the target to be overloaded, or 644 o Directing traffic addressed to the target to a place 645 where the attacker can copy, snoop, alter, or otherwise 646 affect the traffic. 648 Topology Hiding 649 Any new architecture and protocols must provide mechanisms 650 to allow network owners to hide the details of their 651 internal topologies, yet maintaining the desired levels of 652 service connectivity and reachability. 654 Privacy 655 By "privacy" we mean privacy of the routing protocol 656 exchanges between routers. In the past this has not been 657 considered important for routing protocols. 659 When the routers are on point-to-point links, with routers 660 at each end, there is no need to encrypt the routing 661 protocol traffic; there is no possibility of a third party 662 intercepting the traffic, and if one of the two routers are 663 compromised then it doesn't matter. This is not sufficient. 664 We believe that it is important to have the ability to 665 protect routing protocol traffic in two cases: 666 1. When the routers are on a shared network it is possible 667 that there are hosts on the network that have been 668 compromised. These hosts could surreptitiously monitor 669 the protocol traffic. 670 2. When two routers are exchanging information "at a 671 distance" (over intervening routers and, possibly, 672 administrative domains). In this case, the security of 673 the intervening routers, links, and so on, cannot be 674 assured. Thus, the ability to encrypt this traffic is 675 important. 677 Therefore, we believe that the option to encrypt routing 678 protocol traffic is required. 680 Data Consistency 681 A router should be able to detect and recover from any data 682 that is received from other routers which is inconsistent. 683 That is, it MUST NOT be possible for data from multiple 684 routers, none of which is malicious, to "break" another 685 router. 687 Where security mechanisms are provided, they must use methods 688 that are considered to be cryptographically secure (e.g. using 689 cryptographically strong encryption and signatures -- no clear 690 text passwords!). 692 Use of security features SHOULD NOT be optional (except as 693 required above). This may be "social engineering" on our part, 694 but we believe it to be necessary. If a security feature is 695 optional, the implementation of the feature MUST default to the 696 "secure" setting. 698 3.10 End Host Security 700 The Architecture MUST NOT prevent individual host-to-host 701 communications sessions from being secured (i.e. it cannot 702 interfere with things like IPSEC). 704 3.11 Rich Policy 706 Before setting out Policy requirements, we need to define the 707 term. Like "security", "policy" means many things to many 708 people. For our purposes, we define policy as 710 Policy is the set of administrative influences that alter 711 the path determination and next-hop selection procedures of 712 the routing software. 714 The main motivators for influencing path and next-hop selection 715 seem to be transit rules, business decisions and load 716 management. 718 The new Architecture must support rich policy mechanisms. 719 Furthermore, the policy definition and dissemination 720 mechanismsshould be separated from the network topology and 721 connectivity dissemination mechanisms. Policy provides input 722 to and controls the generation of the forwarding table and the 723 abstraction, filtering, aggregation, and dissemination of 724 topology information. 726 Note that if the architecture is properly divided into 727 subsystems then at a later time, new policy subsystems that 728 include new features and capabilities could be developed and 729 installed as needed. 731 We divide the general area of policy into two sub-categories, 732 routing information and traffic control. Routing Information 733 Policies control what routing information is disseminated or 734 accepted, how it is disseminated, and how routers determine 735 paths and next-hops from the received information. Traffic 736 Control Policies determine how traffic is classified and 737 assigned to routes. 739 3.11.1 Routing Information Policies 741 There must be mechanisms to allow network administrators, 742 operators, and designers to control receipt and dissemination 743 of routing information. These controls include, but are not 744 limited to: 745 - Selecting to which others routing information will be 746 transmitted. 747 - Specifying the "granularity" and type of transmitted 748 information. The length of IPv4 prefixes is an example of 749 "granularity". 750 - Selection and filtering of topology and service information 751 that is transmitted. This gives different 'views' of 752 internal structure and topology to different peers. 753 - Selecting the level of security and authenticity for 754 transmitted information 755 - Being able to cause the level of detail that is visible for 756 some portion of the network to reduce the farther you get 757 from that part of the network. 758 - Selecting from whom routing information will be accepted. 759 This control should be "provisional" in the sense of "accept 760 routes from "foo" only if there are no others available". 761 - Accepting or rejecting routing information based on the path 762 the information traveled (using the current system as an 763 example, this would be filtering routes based on an AS 764 appearing anywhere in the AS path). This control should be 765 "provisional" in the sense of "accept routes that traverse 766 "foo" only if there are no others available". 767 - Selecting the desired level of "granularity" for received 768 routing information (this would include, but is not limited 769 to, things similar in nature to the prefix-length filters 770 widely used in the current routing and addressing system). 771 - Selecting the level of security and authenticity of received 772 information in order for that information to be accepted. 773 - Determining the treatment of received routing information 774 based on attributes supplied with the information. 775 - Applying attributes to routing information that is to be 776 transmitted and then determining treatment of information 777 (eg, sending it "here" but not "there") based on those tags. 778 - Selection and filtering of topology and service information 779 that is received. 781 3.11.2 Traffic Control Policies 783 The architecture SHOULD provide mechanisms that allow network 784 operators to manage and control the flow of traffic. The 785 traffic controls should include, but are not limited to: 786 - The ability to detect and eliminate congestion points in the 787 network (by re-directing traffic around those points) . 788 - The ability to develop multiple paths through the network 789 with different attributes and then assign traffic to those 790 paths based on some discriminators within the packets 791 (discriminators include, but are not limited to, IP Addresses 792 or prefixes, DSCP values, and MPLS labels) . 794 - The ability to to find and use multiple, equivalent, paths 795 through the network (i.e. they would have the "same" 796 attributes) and allocate traffic across the paths. 797 - The ability to accept or refuse traffic based on some traffic 798 classification (providing, in effect, transit policies). 800 Traffic classification must at least include the source and 801 destination IP addresses (prefixes) and the DSCP value. Other 802 fields may be supported, such as 803 o Protocol and port based functions, 804 o TOS/QOS tuple (such as ports) 805 o Per-host operations (i.e. /32s for IPv4 and /128s for 806 IPv6), 807 o Traffic matrices (e.g., traffic from prefix X and to 808 prefix Y). 810 3.12 Incremental Deployment 812 The reality of the Internet is that there can be no Internet- 813 wide cutover from one architecture and protocol to another. 814 This means that any new architecture and protocol MUST be 815 incrementally deployable; ISPs must be able to set up small 816 sections of the new architecture, check it out, and then slowly 817 grow the sections. Eventually, these sections will "touch" and 818 "squeeze out" the old architecture. 820 The protocols that implement the Architecture MUST be able to 821 interoperate at "production levels" with currently existing 822 routing protocols. Furthermore, the protocol specifications 823 MUST define how the interoperability is done. 825 We also believe that sections of the Internet will never 826 convert over to the new architecture. Thus, it is important 827 that the new architecture and its protocols be able to 828 interoperate with "old architecture" regions of the network 829 indefinitely. 831 The architecture's addressing system MUST NOT force existing 832 address allocations to be redone: no renumbering! 834 3.13 Mobility 836 There are two kinds of mobility; host mobility and network 837 mobility. Host mobility is when an individual host moves from 838 where it was to where it is. Network mobility is when an 839 entire network (or subnetwork) moves. 841 The architecture MUST support network level mobility. 843 3.14 Address Portability 845 One of the big "hot items" in the current Internet political 846 climate is portability of IP addresses (both V4 and V6). The 847 short explanation is that people do not like to renumber and do 848 not trust automated renumbering tools. 850 The Architecture MUST provide complete address portability. 852 3.15 Multi-Protocol 854 The Internet is expected to be "multi-protocol" for at least 855 the next several years. IPv4 and IPv6 will co-exist in many 856 different ways during a transition period. The architecture 857 MUST be able to handle both IPv4 and IPv6 addresses. 858 Furthermore, protocols that supplant IPv4 and IPv6 may be 859 developed and deployed during the lifetime of the architecture. 860 The architecture MUST be flexible and extensible enough to 861 handle new protocols as they arise. 863 Furthermore, the architecture MUST NOT assume any given 864 relationships between a topological element's IPv4 address and 865 its IPv6 address. The architecture MUST NOT assume that all 866 topological elements have IPv4 addresses/prefixes, nor can it 867 assume that they have IPv6 addresses/prefixes. 869 The architecture SHOULD allow different paths to the same 870 destination to be used for different protocols, even if all 871 paths can carry all protocols. 873 In addition to the addressing technology, the architecture need 874 not be restricted to only packet based 875 multiplexing/demultiplexing technology (such as IP); support 876 for other multiplexing/ demultiplexing technologies MAY be 877 added. 879 3.16 Abstraction 881 The architecture must provide mechanisms to for network 882 designers and operators to 883 o Group elements together for administrative control 884 purposes, 885 o Hide the internal structure and topology of those 886 groupings for administrative and security reasons, 887 o Limit the amount of topology information that is exported 888 from the groupings in order to control the load placed on 889 external routers, 890 o Define rules for traffic transiting or terminating in the 891 grouping. 893 The architecture MUST allow the current Autonomous System 894 structure to be mapped into any new abstraction schemes. 896 Mapping mechanisms, algorithms, and techniques MUST be 897 specified. 899 3.17 Simplicity 901 The architecture MUST be simple enough so that Radia Perlman 902 can explain all the important concepts in less than an hour. 904 The requirement is that the routing architecture be kept as 905 simple as possible. This requires careful evaluation of 906 possible features and functions with a merciless weeding out of 907 those that "might be nice". 909 By keeping the architecture simple, the protocols and software 910 used to implement the architecture are simpler. This 911 simplicity in turn leads to: 912 1. Faster implementation of the protocols. If there are fewer 913 bells and whistles, then there are fewer things that need to 914 be implemented. 915 2. More reliable implementations. With fewer components, there 916 is less code, reducing bug counts, and fewer interactions 917 between components that could lead to unforeseen and 918 incorrect behavior. 920 3.18 Robustness 922 The architecture, and the protocols implementing it, should be 923 robust. Robustness comes in many different flavors. Some 924 considerations with regard to robustness include (but are not 925 limited to): 926 o Defective (even malicious) trusted routers. 927 o Network failures. Whenever possible, valid alternate 928 paths are to be found and used. 929 o Failures must be localized. That is, the architecture 930 must limit the "spread" of any adverse effects of a 931 misconfiguration or failure. Badness must not spread. 933 Of course, the general robustness principle of being liberal in 934 what's accepted and conservative in what's sent must also be 935 applied. 937 EDITOR'S NOTE: 938 Some of the contributors to this note have argued that 939 robustness is an aspect of Security. I have exercised 940 editor's discretion by making it a separate section. 941 The reason for this is that to too many people 942 "security" means "protection from breakins" and 943 "authenticating and encrypting data". This requirement 944 goes beyond those views. 946 3.19 Media Independence 948 While it is an article of faith that IP operates over a wide 949 variety of media (such as Ethernet, X.25, ATM, and so on), IP 950 routing must take an agnostic view towards any "routing" or 951 "topology" services that are offered by the medium over which 952 IP is operating. That is, the new architecture MUST NOT be 953 designed to integrate with any media-specific topology 954 management or routing scheme. 956 The routing architecture must assume, and must work over, the 957 simplest possible media. 959 The routing and addressing architecture can certainly make use 960 of lower-layer information and services, when and where 961 available, and to the extent that IP routing wishes. 963 3.20 Stand-alone 965 The routing architecture and protocols MUST NOT rely on other 966 components of the Internet (such as DNS) for their correct 967 operation. Routing is the fundamental process by which data 968 "finds its way around the Internet" and most, if not all, of 969 those other components rely on routing to properly forward 970 their data. Thus, Routing cannot rely on any Internet systems, 971 services or capabilities that in turn rely on Routing. If it 972 did, a dependency loop would result. 974 3.21 Safety of Configuration 976 The architecture, protocols, and standard implementation 977 defaults must be such that a router installed "out of the box" 978 with no configuration/etc by the operators will not cause "bad 979 things" to happen to the rest of the routing system (no dialup 980 customers advertising routes to 18/8!) 982 3.22 Renumbering 984 The routing system MUST allow topological entities to be 985 renumbered. 987 3.23 Multi-prefix 989 The architecture MUST allow topological entities to have 990 multiple prefixes (or the equivalent under the new 991 architecture). 993 3.24 Cooperative Anarchy 995 As RFC1726[5] said: 997 A major contributor to the Internet's success is the fact 998 that there is no single, centralized, point of control or 999 promulgator of policy for the entire network. This allows 1000 individual constituents of the network to tailor their own 1001 networks, environments, and policies to suit their own needs. 1002 The individual constituents must cooperate only to the degree 1003 necessary to ensure that they interoperate. 1005 This decentralization, called "cooperative anarchy", is still a 1006 key feature of the Internet today. The new routing 1007 architecture MUST retain this feature. There can be no 1008 centralized point of control or promulgator of policy for the 1009 entire Internet. 1011 3.25 Network Layer Protocols and Forwarding Model 1013 For the purposes of backward compatibility, any new routing and 1014 addressing architecture and protocols MUST work with IPv4 and 1015 IPv6 using the traditional "hop by hop" forwarding and packet- 1016 based multiplex/demultiplex models. However, the architecture 1017 need not be restricted to these models. Additional forwarding 1018 and multiplex/demultiplex models MAY be added. 1020 3.26 Routing Algorithm 1022 The architecture SHOULD NOT require a particular routing 1023 algorithm family. That is to say, the architecture should be 1024 agnostic with regard to using link-state, distance-vector, or 1025 path-vector routing algorithms. 1027 3.27 Positive Benefit 1029 Finally, the architecture must show benefits, in terms of 1030 increased stability, decreased operational costs, and increased 1031 functionality and lifetime over the current schemes. This 1032 benefit must remain even after the inevitable costs of 1033 developing and debugging the new protocols, enduring the 1034 inevitable instabilities as things get shaken out, and so on. 1036 3.28 Administrative Entities and the IGP/EGP Split 1038 We explicitly recognize that the Internet consists of resources 1039 under control of multiple administrative entities. Each entity 1040 MUST be able to manage its own portion of the Internet as it 1041 sees fit. Moreover, the constraints that can be imposed on 1042 routing and addressing on the portion of the Internet under the 1043 control of one administration may not be feasibly extended to 1044 cover multiple administrations. Therefore, we recognize a 1045 natural and inevitable split between routing and addressing 1046 that is under a single administrative control and routing and 1047 addressing that involves multiple administrative entities. 1048 Moreover, while there may be multiple administrative 1049 authorities, the administrative authority boundaries may be 1050 complex and overlapping, rather than being a strict hierarchy. 1052 Furthermore, there may be multiple levels of administration, 1053 each with its own level of policy and control. For example, a 1054 large network might have "continental-level" administrations 1055 covering its European and Asian operations, respectively. 1056 There would also be that network's "inter-continental" 1057 administration covering the Europe-to-Asia links. Finally, 1058 there would be the "Internet" level in the administrative 1059 structure (analogous to the "exterior" concept in the current 1060 routing architecture). 1062 Thus, we believe that the administrative structure of the 1063 Internet must be extensible to many levels (more than the two 1064 provided by the current IGP/EGP split). The interior/exterior 1065 property is not absolute. The interior/exterior property of 1066 any point in the network is relative; a point on the network is 1067 interior with respect to some points on the network and 1068 exterior with respect to others. 1070 Administrative entities may not trust each other; some may be 1071 almost actively hostile towards each other. The architecture 1072 MUST accommodate these models. Furthermore, the architecture 1073 MUST NOT require any particular level of trust among 1074 administrative entities. 1076 4 Non-Requirements 1078 The following are not required or are non-goals. This should 1079 not be taken to mean that these issues must not be addressed by 1080 a new architecture. Rather, addressing these issues or not is 1081 purely a matter for the architects. 1083 4.1 Forwarding Table Optimization 1085 We believe that it is not necessary for the architecture to 1086 minimize the size of the forwarding tables (FIBS). Current 1087 memory sizes, speeds, and prices, along with processor and ASIC 1088 capabilities allow forwarding tables to be very large, O(E6), 1089 and fast (100M lookups/second) tables to be built with little 1090 difficulty. 1092 4.2 Traffic Engineering 1094 Traffic Engineering is one of those terms that has become 1095 terribly overloaded. If you ask N people what traffic 1096 engineering is, you get something like N! disjoint answers. 1097 Therefore, we elect not to require "traffic engineering", per 1098 se. Instead, we have endeavored to determine what the ultimate 1099 intent is when operators "traffic engineer" their networks and 1100 then make those capabilities an inherent part of the system. 1102 4.3 Multicast 1104 The new architecture is not designed explicitly to be an inter- 1105 domain multicast routing architecture. However, given the 1106 notable lack of a viable, robust, and widely deployed inter- 1107 domain multicast routing architecture, the architecture should 1108 not hinder the development and deployment of inter-domain 1109 multicast routing without adverse effect on meeting the other 1110 requirements. 1112 We do note however that one respected network sage has said 1113 (roughly) 1114 When you see a bunch of engineers standing around 1115 congratulating themselves for solving some particularly 1116 ugly problem in networking, go up to them, whisper 1117 "multicast", jump back, and watch the fun begin... 1119 4.4 QOS 1121 The Architecture concerns itself primarily with disseminating 1122 network topology information so that routers may select paths 1123 to destinations and build appropriate forwarding tables. QOS 1124 is not a part of this function and we make no requirements with 1125 respect to QOS. 1127 However, QOS is an area of great and evolving interest. It is 1128 reasonable to expect that in the not too distant future, 1129 sophisticated QOS facilities will be deployed in the Internet. 1130 Any new architecture and protocols should be developed with an 1131 eye towards these future evolutions. Extensibility mechanisms, 1132 allowing future QOS routing and signaling protocols to "piggy- 1133 back" on top of the basic routing system are desired. 1135 We do require the ability to assign attributes to entities and 1136 then do path generation and selection based on those 1137 attributes. Some may call this QOS. 1139 4.5 IP Prefix Aggregation 1141 There is no specific requirement that CIDR-style IP Prefix 1142 aggregation be done by the new architecture. Address 1143 allocation policies, societal pressure, and the random growth 1144 and structure of the Internet have all conspired to make prefix 1145 aggregation extraordinarily difficult, if not impossible. This 1146 means that large numbers of prefixes will be sloshing about in 1147 the routing system and that forwarding tables will grow quite 1148 big. This is a cost that we believe must be borne. 1150 Nothing in this non-requirement should be interpreted as saying 1151 that prefix aggregation is explicitly prohibited. CIDR-style 1152 IP Prefix aggregation might be used as a mechanism to meet 1153 other requirements, such as scaling. 1155 4.6 Perfect Safety 1157 Making the system impossible to misconfigure is, we believe, 1158 not required. The checking, constraints, and controls 1159 necessary to achieve this could, we believe, prevent operators 1160 from performing necessary tasks in the face of unforeseen 1161 circumstances. 1163 However, safety is always a "good thing", and any results from 1164 research in this area should certainly be taken into 1165 consideration and, where practical, incorporated into the new 1166 routing architecture. 1168 4.7 Dynamic Load Balancing 1170 Past history has shown that using the routing system to perform 1171 highly dynamic load balancing among multiple more-or-less-equal 1172 paths usually ends up causing all kinds of instability, etc, in 1173 the network. Thus, we do not require such a capability. 1175 However, this is an area that is ripe for additional research, 1176 and some believe that the capability will be necessary in the 1177 future. Thus, the architecture and protocols should be 1178 "malleable" enough to allow development and deployment of 1179 dynamic load balancing capabilities, should we ever figure out 1180 how to do it. 1182 4.8 Renumbering of hosts and routers 1184 We believe that the routing system is not required to "do 1185 renumbering" of hosts and routers. That's an IP issue. 1187 Of course, the routing and addressing architecture must be able 1188 to deal with renumbering when it happens. 1190 4.9 Host Mobility 1192 In the Internet Architecture, host-mobility is handled on a 1193 per-host basis by a dedicated, Mobile-IP protocol [6]. Traffic 1194 destined for a mobile-host is explicitly forwarded by dedicated 1195 relay agents. Mobile-IP [6] adequately solves the host- 1196 mobility problem and we do not see a need for any additional 1197 requirements in this area. Of course, the new architecture 1198 MUST NOT impede or conflict with Mobile-IP. 1200 4.10 Clean Slate 1202 For the purposes of development of the architecture, we assume 1203 that there is a 'clean slate'. Unless specified in section 3, 1204 we have no explicit requirements that elements, concepts or 1205 mechanisms of the current routing architecture are carried 1206 forward into the new one. 1208 5 Discussion of other Inter-Domain Routing Requirements documents 1210 Recently, two other Internet Drafts have been published that 1211 set out some requirements for a new Inter-Domain routing 1212 architecture. These drafts are "Future Domain Routing 1213 Requirements" by Elwyn Davies, et al [3], and "Architectural 1214 Requirements for Inter-Domain Routing in the Internet" by Geoff 1215 Huston [4]. 1217 Rather than use these documents, we decided to develop our own 1218 set of requirements for a future inter-domain routing 1219 architecture. The reasons are 1221 1. There are requirements in [3] and [4] with which we do not 1222 agree, plus we have additional requirements that are not 1223 in those documents. 1225 2. We do not agree with the methodology in [3] and [4]. In 1226 particular, [3]'s list of requirements seems to us like an 1227 exhaustive list of things, falling dangerously close to 1228 the "My Layer MUST solve all of networking's problems" 1229 disease. One of the hardest parts of setting requirements 1230 is to determine what problems will NOT be solved. 1232 [3] and [4] each provide excellent historical background 1233 information. Rather than repeat the information here, readers 1234 are encouraged to consult those documents. 1236 Discussions and commentary on each internet-draft follow. 1238 5.1 Comments on "Architectural Requirements for Inter-Domain 1240 Routing in the Internet" 1242 The IAB have developed an internet-draft titled "Architectural 1243 Requirements for Inter-Domain Routing in the Internet" [4]. 1244 Rather than using [4], we have produced our own document. 1246 A good part of [4] is a detailed explanation of the current 1247 problems in routing and addressing. This work is valuable. We 1248 chose not to replicate it in this note. 1250 The main reason we decided not to use [4] is that it is too 1251 rooted in the current BGP/AS model. We believe that the 1252 charter for the Routing Research Group is to work on longer- 1253 term futures, including the possibility of replacing that 1254 model. We wish to develop our requirements in a forward- 1255 looking manner and using requirements rooted in the old model 1256 may cause us to unwittingly constrain our thinking. 1258 [4] Enumerates four requirements for a new routing 1259 architecture. These requirements are fairly broad and loose. 1260 They are: 1262 Scalability 1263 We agree. The new architecture must be scalable. We have 1264 included a requirement for scalability. 1266 Stability and Predictability 1267 Yes, the routing and addressing architecture should be 1268 stable and predictable. However, we are not sure that 1269 overall this is possible. 1271 Convergence 1272 Fast convergence would be nice. However, the size and 1273 complexity of the Internet are such that we do not believe 1274 that the entire net can ever converge. Changes with global 1275 impact will always be happening and their effects will be 1276 constantly propagating through the network. We expect that 1277 any routing system will, at best, be able to converge 1278 incrementally. That is, in any one place, convergence with 1279 respect to one change can occur, but before the entire net 1280 converges, another change will occur, requiring a new set 1281 of calculations and a "new" convergence. 1283 We prefer to believe that convergence at any single point 1284 and after any single change must occur quickly. Also, 1285 since we expect that the network will constantly by (re- 1286 converging, so the load of those attempts must be minimal. 1288 Routing Overhead 1289 Routing overhead should be minimized. True. 1291 5.2 Comments on "Future Domain Routing Requirements" 1293 A separate group is developing a document titled "Future Domain 1294 Routing Requirements" [3]. 1296 Rather than using [3], we have produced our own document. As 1297 with [4] we believe that this document is too rooted in the 1298 current BGP/AS model, which is not a useful context for 1299 developing long-term future architectures. 1301 We have a number of observations on [3], in no particular 1302 order: 1304 1. The introductory/historical/background is fine. In fact, 1305 that material should be considered "required reading" to 1306 understand the background and current problems of Internet 1307 Routing. We commend the authors of [3] for putting this 1308 material together. 1310 2. The "goals" section (1.2) seems to be heavily oriented to 1311 specific issues and tasks that network designers and 1312 administrators face today. Our charter calls for us to 1313 consider the very long term. Thus, it is hard to say what 1314 specific tasks the operations community needs to perform. 1315 Therefore, we prefer to take a broader view of what 1316 routing should do and have written our document 1317 accordingly. 1319 3. [3] Seems still wedded to the old BGP/AS model of doing 1320 inter-domain routing. That may well be an adequate model. 1321 However, the Routing Research Group's charter is to 1322 consider and develop long-term future directions in 1323 routing. We prefer to develop our own document, trying to 1324 avoid falling into the "traps" of the past. 1326 4. The document seems to be an exhaustive wish list of 1327 things. The hardest part of doing requirements is to 1328 figure out what not to require. Coincident with that 1329 observation, there were a couple of "would be nice" and 1330 "might be needed" sorts of things. The fear is that they 1331 fell into the trap of "All problems must be solved in our 1332 layer", which leads to very poor architectures and 1333 designs. 1335 5. They call for "support for NATs and other mid-boxes". If 1336 the Routing and Addressing architecture is "right" then 1337 there is no need for them, at least as far as Routing and 1338 Addressing are concerned. 1340 Also, we are confused as to what "support for NATs..." 1341 actually means. 1343 6. The authors of [3] talk a fair bit about some low-level 1344 things they want. Our opinion is that we are looking "too 1345 far out" to talk about detailed, low-level requirements. 1346 We don't know what the operators of 2007 will want. 1347 Besides solving the basic problem of getting topological 1348 and addressing information "around", we need to think more 1349 about how to keep the architecture (and design and 1350 implementation) flexible and open so that in 2006 when 1351 someone says "We need a gonkulator!" we can say "Easy, it 1352 gets plugged in here..." 1354 7. Multicast/Anycast 1355 We do not believe that multicast routing is a part of our 1356 charter. 1358 Anycast is a fairly nebulous technology. To require that 1359 routing "support" it at this stage in its development is 1360 premature. To require that routing support anycast means, 1361 in effect, that we first define what it is. 1363 8. Support for renumbering 1364 We take this to mean either that 1365 o The routing-and-addressing system actually does the 1366 renumbering, to which we reply "Is this really 1367 something for routing to do?", or 1368 o The routing-and-addressing system must continue to 1369 operate when elements of the network are renumbered. 1370 We have a requirement for this 1372 9. Statistics support 1373 This seems to us to be a low-level protocol issue. Yes 1374 the protocol needs a MIB. But we do not believe that this 1375 is an architectural or requirements issue. 1377 This also indicates to us that [3] is more concerned with 1378 lower-level protocol and implementation issues rather than 1379 taking the proverbial "step back" to look at "the big 1380 picture". 1382 10. There were some comments about convergence that 1383 seemed to indicate that the authors of [3] are thinking of 1384 global convergence. We have observed that global 1385 convergence is probably not doable anymore. We believe 1386 that "permanent change" is the order of the day... 1388 11. One of their open-issues indicates that the 1389 authors of [3] are thinking about whether the EGP/IGP 1390 split is good or not. It's good they are thinking about 1391 it. It's bad that they consider it open. We consider 1392 this split to be A Bad Thing -- there should be no such 1393 split in the architecture. 1395 12. One example of the too fine a level of detail they 1396 are getting into is that in 7.2.2 they talk about having a 1397 number of specific path attributes. But, if say in 2007 1398 we discover a need for a gonkulation attribute, it's not 1399 in the list in [3]. Perhaps we are taking their document 1400 too literally, but someone taking [3] and designing to it 1401 would maybe make attributes TLV's and leave it at that. 1402 They wouldn't consider the effects of unconsidered new 1403 attributes. We prefer to think of things in the reverse 1404 order: 1406 We know we need attributes, but we don't know what they 1407 all are. Therefore the attribute mechanism must be 1408 flexible and allow growth in weird new directions 1409 without causing problems on the rest of the system -- 1410 so how do we do that. 1412 6 Security Considerations 1414 We address security issues in the individual requirements. We 1415 do require that the Architecture and protocols developed 1416 against this set of requirements be "secure". 1418 7 IANA Considerations 1420 This document is a set of requirements from which a new routing 1421 and addressing architecture will be developed. From that 1422 architecture, a new protocol, or set of protocols, may be 1423 developed. 1425 While this note poses no new tasks for IANA, the architecture 1426 and protocols developed from this document probably will have 1427 issues to be dealt with by IANA. 1429 8 References 1431 [1] Bradner, S., "The Internet Standards Process � Revision 3", 1432 BCP9, RFC2026, October 1996. 1434 [2] Bradner, S., "Key words for use in RFCs to Indicate 1435 Requirements Levels", BCP 14 RFC 2119, March 1997. 1437 [3] Davies, E., et al, "Future Domain Routing Requirements", 1438 draft-davies-fdr-reqs-01.txt, July 2001, Work In Progress. 1440 [4] Huston, G., "Architectural Requirements for Inter-Domain 1441 Routing in the Internet" draft-iab-bgparch-01.txt, May 1442 2001, Work In Progress. 1444 [5] Partridge, C., and F. Kastenholz, "Technical Criteria for 1445 Choosing IP The Next Generation (IPng)", RFC 1726. December 1446 1994. 1448 [6] Perkins, C., "IP Mobility Support." RFC2002, October 1996. 1450 9 Acknowledgments 1452 This originated in the IRTF Routing Research Group�s sub-group 1453 on Inter-domain routing requirements. The members of the group 1454 are 1456 Abha Ahuja Danny McPherson 1457 J. Noel Chiappa David Meyer 1458 Sean Doran Mike O�Dell 1459 JJ Garcia-Luna-Aceves Andrew Partan 1460 Susan Hares Radia Perlman 1461 Geoff Huston Yakov Rehkter 1462 Frank Kastenholz John Scudder 1463 Dave Katz Curtis Villamizar 1464 Tony Li Dave Ward 1466 We also appreciate the comments and review received from Ran 1467 Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery 1468 Haas, Dmitri Krioukov, Russ White, and Alex Zinin. Special 1469 thanks to Yakov Rehkter for contributing text and to Noel 1470 Chiappa. 1472 10 Editor's Addresses 1474 Frank Kastenholz 1475 Unisphere Networks 1476 10 Technology Park 1477 Westford, MA, 01886, USA 1479 Phone: +1 978 589 0286 1480 Email: fkastenholz@unispherenetworks.com 1481 Full Copyright Statement 1483 Copyright (C) The Internet Society (2001). All Rights Reserved. 1485 This document and translations of it may be copied and 1486 furnished to others, and derivative works that comment on or 1487 otherwise explain it or assist in its implementation may be 1488 prepared, copied, published and distributed, in whole or in 1489 part, without restriction of any kind, provided that the above 1490 copyright notice and this paragraph are included on all such 1491 copies and derivative works. However, this document itself may 1492 not be modified in any way, such as by removing the copyright 1493 notice or references to the Internet Society or other Internet 1494 organizations, except as needed for the purpose of developing 1495 Internet standards in which case the procedures for copyrights 1496 defined in the Internet Standards process must be followed, or 1497 as required to translate it into languages other than English. 1499 The limited permissions granted above are perpetual and will 1500 not be revoked by the Internet Society or its successors or 1501 assigns. 1503 This document and the information contained herein is provided 1504 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1505 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1506 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1507 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1508 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1509 PARTICULAR PURPOSE.