A Set of Possible Requirements for a Future Routing Architecture
RFC 5772
Document | Type |
RFC - Historic
(February 2010; No errata)
Was draft-irtf-routing-reqs (gen)
|
|
---|---|---|---|
Authors | Avri Doria , Frank Kastenholz , Elwyn Davies | ||
Last updated | 2018-12-20 | ||
Stream | Internet Research Task Force (IRTF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | IRTF state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5772 (Historic) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
Internet Research Task Force (IRTF) A. Doria Request for Comments: 5772 LTU Category: Historic E. Davies ISSN: 2070-1721 Folly Consulting F. Kastenholz BBN Technologies February 2010 A Set of Possible Requirements for a Future Routing Architecture Abstract The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5772. Doria, et al. Historic [Page 1] RFC 5772 IRTF Routing Requirements February 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. Table of Contents 1. Background ......................................................4 2. Results from Group A ............................................5 2.1. Group A - Requirements for a Next Generation Routing and Addressing Architecture ....................................5 2.1.1. Architecture ........................................6 2.1.2. Separable Components ................................6 2.1.3. Scalable ............................................7 2.1.4. Lots of Interconnectivity ..........................10 2.1.5. Random Structure ...................................10 2.1.6. Multi-Homing .......................................11 2.1.7. Multi-Path .........................................11 2.1.8. Convergence ........................................12 2.1.9. Routing System Security ............................14 2.1.10. End Host Security .................................16 2.1.11. Rich Policy .......................................16 2.1.12. Incremental Deployment ............................19 2.1.13. Mobility ..........................................19 2.1.14. Address Portability ...............................20 2.1.15. Multi-Protocol ....................................20 2.1.16. Abstraction .......................................20 2.1.17. Simplicity ........................................21 2.1.18. Robustness ........................................21 2.1.19. Media Independence ................................22 2.1.20. Stand-Alone .......................................22 2.1.21. Safety of Configuration ...........................23 2.1.22. Renumbering .......................................23 2.1.23. Multi-Prefix ......................................23 2.1.24. Cooperative Anarchy ...............................23Show full document text