Internet Research Task Force (IRTF) E. Davies
Request for Comments: 5773 Folly Consulting
Category: Historic A. Doria
ISSN: 2070-1721 LTU
February 2010
Internet Research Task Force (IRTF) E. Davies
Request for Comments: 5773 Folly Consulting
Category: Historic A. Doria
ISSN: 2070-1721 LTU
February 2010
Analysis of Inter-Domain Routing Requirements and History
域间路由需求和历史分析
Abstract
摘要
This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. 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.
本文分析了基于Internet域的路由系统的状态，重点介绍了域间路由（IDR），并考虑了域间路由和域内路由之间的关系。该分析是针对RFC 1126和其他IDR要求进行的，设计工作着眼于路由系统，如2001年的情况，编辑补充反映了截至2006年的发展情况。它是“未来路由体系结构的一组可能需求”（RFC 5772）的配套文件，该文件讨论了未来路由体系结构的需求、系统开发和未来路由协议。本文件总结了几年前IRTF路由研究组（IRTF RRG）成员和其他相关方进行的讨论。该文件在IRTF RRG的支持下发布，作为当时完成工作的记录，但有一项谅解，即该文件不一定代表发布之日研究小组的最新技术理解或技术共识。
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.
本文档定义了互联网社区的历史文档。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表互联网研究任务组（IRTF）路由研究组一名或多名成员的个人意见。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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/rfc5773.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5773.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Provenance of This Document .....................................4
2. Introduction ....................................................5
2.1. Background .................................................7
3. Historical Perspective ..........................................7
3.1. The Legacy of RFC 1126 .....................................7
3.1.1. General Requirements ................................8
3.1.2. "Functional Requirements" ..........................13
3.1.3. "Non-Goals" ........................................21
3.2. ISO OSI IDRP, BGP, and the Development of Policy Routing ..25
3.3. Nimrod Requirements .......................................30
3.4. PNNI ......................................................32
4. Recent Research Work ...........................................33
4.1. Developments in Internet Connectivity .....................33
4.2. DARPA NewArch Project .....................................34
4.2.1. Defending the End-to-End Principle .................35
5. Existing Problems of BGP and the Current Inter-/Intra-Domain
Architecture ...................................................35
5.1. BGP and Auto-Aggregation ..................................36
5.2. Convergence and Recovery Issues ...........................36
5.3. Non-Locality of Effects of Instability and
Misconfiguration ..........................................37
5.4. Multi-Homing Issues .......................................37
5.5. AS Number Exhaustion ......................................38
5.6. Partitioned ASs ...........................................39
5.7. Load Sharing ..............................................40
5.8. Hold-Down Issues ..........................................40
5.9. Interaction between Inter-Domain Routing and
Intra-Domain Routing ......................................40
5.10. Policy Issues ............................................42
5.11. Security Issues ..........................................42
5.12. Support of MPLS and VPNS .................................43
5.13. IPv4/IPv6 Ships in the Night .............................43
5.14. Existing Tools to Support Effective Deployment of
Inter-Domain Routing .....................................44
5.14.1. Routing Policy Specification Language RPSL
(RFC 2622 and RFC 2650) and RIPE NCC Database
(RIPE 157) ........................................44
6. Security Considerations ........................................45
7. Acknowledgments ................................................45
8. Informative References .........................................46
1. Provenance of This Document .....................................4
2. Introduction ....................................................5
2.1. Background .................................................7
3. Historical Perspective ..........................................7
3.1. The Legacy of RFC 1126 .....................................7
3.1.1. General Requirements ................................8
3.1.2. "Functional Requirements" ..........................13
3.1.3. "Non-Goals" ........................................21
3.2. ISO OSI IDRP, BGP, and the Development of Policy Routing ..25
3.3. Nimrod Requirements .......................................30
3.4. PNNI ......................................................32
4. Recent Research Work ...........................................33
4.1. Developments in Internet Connectivity .....................33
4.2. DARPA NewArch Project .....................................34
4.2.1. Defending the End-to-End Principle .................35
5. Existing Problems of BGP and the Current Inter-/Intra-Domain
Architecture ...................................................35
5.1. BGP and Auto-Aggregation ..................................36
5.2. Convergence and Recovery Issues ...........................36
5.3. Non-Locality of Effects of Instability and
Misconfiguration ..........................................37
5.4. Multi-Homing Issues .......................................37
5.5. AS Number Exhaustion ......................................38
5.6. Partitioned ASs ...........................................39
5.7. Load Sharing ..............................................40
5.8. Hold-Down Issues ..........................................40
5.9. Interaction between Inter-Domain Routing and
Intra-Domain Routing ......................................40
5.10. Policy Issues ............................................42
5.11. Security Issues ..........................................42
5.12. Support of MPLS and VPNS .................................43
5.13. IPv4/IPv6 Ships in the Night .............................43
5.14. Existing Tools to Support Effective Deployment of
Inter-Domain Routing .....................................44
5.14.1. Routing Policy Specification Language RPSL
(RFC 2622 and RFC 2650) and RIPE NCC Database
(RIPE 157) ........................................44
6. Security Considerations ........................................45
7. Acknowledgments ................................................45
8. Informative References .........................................46
In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha Ahuja and Sean Doran, decided to establish a sub-group to look at requirements for inter-domain routing (IDR). A group of well-known routing experts was assembled to develop requirements for a new routing architecture. Their mandate was to approach the problem starting from a blank slate. This group was free to take any approach, including a revolutionary approach, in developing requirements for solving the problems they saw in inter-domain routing. Their eventual approach documented requirements for a complete future routing and addressing architecture rather than just the requirements for IDR.
2001年，IRTF路由研究组（IRTF RRG）主席Abha Ahuja和Sean Doran决定成立一个小组，研究域间路由（IDR）的要求。一组著名的路由专家被召集起来，为新的路由架构开发需求。他们的任务是从一张白纸开始处理这个问题。这个团队可以自由地采取任何方法，包括革命性的方法，来开发解决域间路由问题的需求。他们的最终方法记录了未来完整路由和寻址体系结构的需求，而不仅仅是IDR的需求。
Simultaneously, an independent effort was started in Sweden with a similar goal. A team, calling itself Babylon, with participation from vendors, service providers, and academia, assembled to understand the history of inter-domain routing, to research the problems seen by the service providers, and to develop a proposal of requirements for a follow-on to the current routing architecture. This group's approach required an evolutionary approach starting from current routing architecture and practice. In other words, the group limited itself to developing an evolutionary strategy and consequently assumed that the architecture would probably remain domain-based. The Babylon group was later folded into the IRTF RRG as Sub-Group B to distinguish it from the original RRG Sub-Group A.
与此同时，瑞典也开始了一项独立的努力，目标与此类似。一个自称巴比伦的团队，由供应商、服务提供商和学术界参与，集合起来了解域间路由的历史，研究服务提供商所看到的问题，并为当前路由体系结构的后续发展制定需求建议。该小组的方法需要从当前的路由架构和实践出发，采用一种渐进的方法。换句话说，该小组仅限于开发一种进化策略，因此认为该体系结构可能仍然是基于领域的。巴比伦群后来被折叠成IRTF RRG，作为B亚群，以区别于原始RRG亚群A。
This document, which was a part of Sub-Group B's output, provides a snapshot of the state of Inter-Domain Routing (IDR) at the time of original writing (2001) with some minor updates to take into account developments since that date, bringing it up to date in 2006. The development of the new requirements set was then motivated by an analysis of the problems that IDR has been encountering in the recent past. This document is intended as a counterpart to the Routing Requirements document ("A Set of Possible Requirements for a Future Routing Architecture"), which documents the requirements for future routing systems as captured separately by the IRTF RRG Sub-Groups A and B [RFC5772].
本文件是子组B输出的一部分，提供了原始编写时（2001年）域间路由（IDR）状态的快照，并进行了一些小的更新，以考虑到自该日期以来的发展，使其在2006年更新。新需求集的开发是基于对IDR最近遇到的问题的分析。本文件旨在作为路由需求文件（“未来路由架构的一组可能需求”）的副本，该文件记录了IRTF RRG子组a和B单独捕获的未来路由系统需求[RFC5772]。
The IRTF RRG supported publication of this document as a historical record of the work completed on the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the time of publication. The document has had substantial review by members of the Babylon team, members of the IRTF RRG, and others over the years.
IRTF RRG支持将本文件作为已完成工作的历史记录出版，但前提是，本文件不一定代表出版时研究小组的最新技术理解或技术共识。多年来，巴比伦团队成员、IRTF RRG成员和其他人对该文件进行了大量审查。
For the greater part of its existence, the Internet has used a domain-oriented routing system whereby the routers and other nodes making up the infrastructure are partitioned into a set of administrative domains, primarily along ownership lines. Individual routing domains (also known as Autonomous Systems (ASs)), which maybe a subset of an administrative domain, are made up of a finite, connected set of nodes (at least in normal operation). Each routing domain is subject to a coherent set of routing and other policies managed by a single administrative authority. The domains are interlinked to form the greater Internet, producing a very large network: in practice, we have to treat this network as if it were infinite in extent as there is no central knowledge about the whole network of domains. An early presentation of the concept of routing domains can be found in Paul Francis' OSI routing architecture paper from 1987 [Tsuchiya87] (Paul Francis was formerly known as Paul Tsuchiya).
在其存在的大部分时间里，互联网使用了一种面向域的路由系统，其中路由器和构成基础设施的其他节点被划分为一组管理域，主要是沿着所有权线。单个路由域（也称为自治系统（ASs）），可能是管理域的子集，由有限的、连接的一组节点组成（至少在正常操作中）。每个路由域都受一组由单个管理机构管理的一致路由和其他策略的约束。这些领域相互联系，形成更大的互联网，产生一个非常大的网络：在实践中，我们必须将这个网络视为无限的，因为没有关于整个领域网络的中心知识。在Paul Francis 1987年发表的OSI路由架构论文[Tsuchiya87]（Paul Francis以前被称为Paul Tsuchiya）中可以找到路由域概念的早期介绍。
The domain concept and domain-oriented routing has become so fundamental to Internet-routing thinking that it is generally taken as an axiom these days and not even defined again (cf., [NewArch03]). The issues discussed in the present document notwithstanding, it has proved to be a robust and successful architectural concept that brings with it the possibility of using different routing mechanisms and protocols within the domains (intra-domain) and between the domains (inter-domain). This is an attractive division, because intra-domain protocols can exploit the well-known finite scope of the domain and the mutual trust engendered by shared ownership to give a high degree of control to the domain administrators, whereas inter-domain routing lives in an essentially infinite region featuring a climate of distrust built on a multitude of competitive commercial agreements and driven by less-than-fully-public policies from each component domain. Of course, like any other assumption that has been around for a very long time, the domain concept should be reevaluated to make sure that it is still helping!
域概念和面向域的路由已经成为互联网路由思想的基础，以至于现在它通常被视为一个公理，甚至不再定义（参见，[NewArch03]）。尽管本文件中讨论了这些问题，但事实证明，这是一个稳健而成功的体系结构概念，它带来了在域内（域内）和域间（域间）使用不同路由机制和协议的可能性。这是一个很有吸引力的划分，因为域内协议可以利用众所周知的域的有限范围和共享所有权所产生的相互信任，为域管理员提供高度的控制，而域间路由存在于一个本质上无限的区域，其不信任气氛建立在众多竞争性商业协议的基础上，并由每个组成域的不完全公共政策驱动。当然，像任何其他已经存在很长时间的假设一样，应该重新评估域概念，以确保它仍然有用！
It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today and that these may result in severe routing problems within an unspecified period of time. Remedying these shortcomings will require extensive research to tie down the exact failure modes that lead to these shortcomings and identify the best techniques to remedy the situation. Comparatively, intra-domain routing works satisfactorily, and issues with intra-domain routing are mainly associated with the interface between intra- and inter-domain routing.
人们普遍认为，当今互联网的域间路由存在重大缺陷，这些缺陷可能会在一段不确定的时间内导致严重的路由问题。纠正这些缺点需要进行广泛的研究，以确定导致这些缺点的确切故障模式，并确定纠正这种情况的最佳技术。相比较而言，域内路由工作令人满意，域内路由问题主要与域内和域间路由之间的接口有关。
Reviewer's Note: Even in 2001, there was a wide difference of opinion across the community regarding the shortcomings of inter-domain routing. In the years between writing and publication, further analysis, changes in operational practice, alterations to the demands made on inter-domain routing, modifications made to BGP and a recognition of the difficulty of finding a replacement may have altered the views of some members of the community.
评论员注：即使在2001年，对于域间路由的缺点，整个社区的意见也有很大差异。在写作和出版之间的几年里，进一步的分析、操作实践的改变、对域间路由的要求的改变、对BGP的修改以及对难以找到替代者的认识，可能改变了一些社区成员的观点。
Changes in the nature and quality of the services that users want from the Internet are difficult to provide within the current framework, as they impose requirements never foreseen by the original architects of the Internet routing system.
在当前的框架内，用户希望从互联网获得的服务的性质和质量的变化是很难提供的，因为它们强加了互联网路由系统的原始架构师从未预见到的要求。
The kind of radical changes that have to be accommodated are epitomized by the advent of IPv6 and the application of IP mechanisms to private commercial networks that offer specific service guarantees beyond the best-effort services of the public Internet. Major changes to the inter-domain routing system are inevitable to provide an efficient underpinning for the radically changed and increasingly commercially-based networks that rely on the IP protocol suite.
IPv6的出现和IP机制在私有商业网络中的应用是必须适应的根本性变化的一个缩影，这些私有商业网络提供公共互联网尽力而为服务之外的特定服务保证。域间路由系统的重大变化是不可避免的，它为依赖IP协议套件的网络提供了一个有效的基础，这些网络已经发生了根本性的变化，并且越来越商业化。
Current practice stresses the need to separate the concerns of the control plane and the forwarding plane in a router: this document will follow this practice, but we still use the term "routing" as a global portmanteau to cover all aspects of the system.
当前实践强调需要在路由器中分离控制平面和转发平面的关注点：本文档将遵循此实践，但我们仍然使用术语“路由”作为全局端口，以涵盖系统的所有方面。
This document provides a historical perspective on the current state of inter-domain routing and its relationship to intra-domain routing in Section 3 by revisiting the previous IETF requirements document intended to steer the development of a future routing system. These requirements, which informed the design of the Border Gateway Protocol (BGP) in 1989, are contained in RFC 1126 -- "Goals and Functional Requirements for Inter-Autonomous System Routing" [RFC1126].
本文件通过回顾先前的IETF需求文件（旨在指导未来路由系统的开发），从历史角度阐述了域间路由的当前状态及其与域内路由的关系（见第3节）。这些要求在1989年为边界网关协议（BGP）的设计提供了依据，包含在RFC 1126——“自治系统间路由的目标和功能要求”[RFC1126]中。
Section 3 also looks at some other work on requirements for domain-based routing that was carried out before and after RFC 1126 was published. This work fleshes out the historical perspective and provides some additional insights into alternative approaches that may be instructive when building a new set of requirements.
第3节还介绍了在RFC1126发布之前和之后进行的一些关于基于域路由需求的其他工作。这项工作充实了历史观点，并提供了一些关于替代方法的额外见解，这些方法在构建一组新的需求时可能具有指导意义。
The motivation for change and the inspiration for some of the requirements for new routing architectures derive from the problems attributable to the current domain-based routing system that are being experienced in the Internet today. These will be discussed in Section 5.
改变的动机和对新路由体系结构的一些需求的灵感来源于当前互联网上正在经历的基于域的路由系统的问题。这些将在第5节中讨论。
Today's Internet uses an addressing and routing structure that has developed in an ad hoc, more or less upwards-compatible fashion. The structure has progressed from supporting a non-commercial Internet with a single administrative domain to a solution that is able to control today's multi-domain, federated Internet, carrying traffic between the networks of commercial, governmental, and not-for-profit participants. This is not achieved without a great deal of 24/7 vigilance and operational activity by network operators: Internet routing often appears to be running close to the limits of stability. As well as directing traffic to its intended endpoint, inter-domain routing mechanisms are expected to implement a host of domain-specific routing policies for competing, communicating domains. The result is not ideal, particularly as regards inter-domain routing mechanisms, but it does a pretty fair job at its primary goal of providing any-to-any connectivity to many millions of computers.
今天的互联网使用一种寻址和路由结构，这种结构是以一种临时的、或多或少向上兼容的方式发展起来的。该结构已从支持具有单个管理域的非商业互联网发展到能够控制当今多域、联合互联网的解决方案，在商业、政府和非营利参与者的网络之间传输流量。如果没有网络运营商的大量24/7警戒和运营活动，这是无法实现的：互联网路由通常看起来接近稳定极限。除了将通信量定向到其预期端点，域间路由机制还将为竞争、通信的域实施一系列特定于域的路由策略。结果并不理想，特别是在域间路由机制方面，但它的主要目标是为数百万台计算机提供任意对任意连接，这一点做得相当不错。
Based on a large body of anecdotal evidence, but also on a growing body of experimental evidence [Labovitz02] and analytic work on the stability of BGP under certain policy specifications [Griffin99], the main Internet inter-domain routing protocol, BGP version 4 (BGP-4), appears to have a number of problems. These problems are discussed in more detail in Section 5. Additionally, the hierarchical nature of the inter-domain routing problem appears to be changing as the connectivity between domains becomes increasingly meshed [RFC3221], which alters some of the scaling and structuring assumptions on which BGP-4 is built. Patches and fix-ups may relieve some of these problems, but others may require a new architecture and new protocols.
基于大量的轶事证据，以及越来越多的实验证据[Labovitz02]和关于BGP在某些政策规范下稳定性的分析工作[Griffin99]，主要的互联网域间路由协议BGP版本4（BGP-4）似乎存在许多问题。第5节将更详细地讨论这些问题。此外，域间路由问题的层次性质似乎正在发生变化，因为域之间的连接变得越来越网状[RFC3221]，这改变了构建BGP-4的一些缩放和结构假设。补丁和修复可能会缓解其中一些问题，但其他问题可能需要新的体系结构和新的协议。
RFC 1126 [RFC1126] outlined a set of requirements that were intended to guide the development of BGP.
RFC 1126[RFC1126]概述了一组旨在指导BGP开发的需求。
Editors' Note: When this document was reviewed by Yakov Rekhter, one of the designers of BGP, his view was that "While some people expected a set of requirements outlined in RFC 1126 to guide the development of BGP, in reality the development of BGP happened completely independently of RFC 1126. In other words, from the point of view of the development of BGP, RFC 1126 turned out to be totally irrelevant". On the other hand, it appears that BGP, as currently implemented, has met a large proportion of these requirements, especially for unicast traffic.
编者按：当BGP的设计师之一雅科夫·雷克特（Yakov Rekhter）审查这份文件时，他的观点是“虽然有些人期望RFC1126中概述的一系列要求能够指导BGP的开发，但实际上BGP的开发完全独立于RFC1126。换句话说，从BGP发展的角度来看，RFC1126被证明是完全不相关的”。另一方面，目前实施的BGP似乎已经满足了这些要求中的很大一部分，特别是对于单播业务。
While the network is demonstrably different from what it was in 1989, having:
虽然该网络与1989年明显不同，但：
o moved from single to multiple administrative control,
o 从单一管理控制转移到多个管理控制，
o increased in size by several orders of magnitude, and
o 尺寸增加了几个数量级，以及
o migrated from a fairly tree-like connectivity graph to a meshier style
o 从相当树状的连接图迁移到网格样式
many of the same requirements remain. As a first step in setting requirements for the future, we need to understand the requirements that were originally set for the current protocols. In charting a future architecture, we must first be sure to do no harm. This means a future domain-based routing system has to support, as its base requirement, the level of function that is available today.
许多相同的要求仍然存在。作为为未来设置需求的第一步，我们需要了解最初为当前协议设置的需求。在规划未来的架构时，我们必须首先确保不会造成伤害。这意味着未来基于域的路由系统必须支持当前可用的功能级别，这是其基本要求。
The following sections each relate to a requirement, or non-requirement listed in RFC 1126. In fact, the section names are direct quotes from the document. The discussion of these requirements covers the following areas:
以下各节分别涉及RFC 1126中列出的要求或非要求。事实上，节名是文档的直接引用。对这些要求的讨论涵盖以下领域：
Explanation: Optional interpretation for today's audience of the original intent of the requirement.
解释：为今天的听众选择解释要求的原意。
Relevance: Is the requirement of RFC 1126 still relevant, and to what degree? Should it be understood differently in today's environment?
相关性：RFC 1126的要求是否仍然相关，相关程度如何？在今天的环境中，是否应该对它有不同的理解？
Current practice: How well is the requirement met by current protocols and practice?
当前实践：当前协议和实践满足要求的程度如何？
Timely routing to all reachable destinations, including multi-homing and multicast.
及时路由到所有可到达的目的地，包括多主和多播。
Relevance: Valid, but requirements for multi-homing need further discussion and elucidation. The requirement should include multiple-source multicast routing.
相关性：有效，但多归宿的要求需要进一步讨论和说明。该要求应包括多源多播路由。
Current practice: Multi-homing is not efficient, and the proposed inter-domain multicast protocol Border Gateway Multicast Protocol (BGMP) [RFC3913] is an add-on to BGP following many of the same strategies but not integrated into the BGP framework.
目前的做法：多宿主并不高效，建议的域间多播协议边界网关多播协议（BGMP）[RFC3913]是BGP的附加协议，遵循许多相同的策略，但未集成到BGP框架中。
Editors' Note: Multicast routing has moved on again since this was originally written. By 2006, BGMP had been effectively superseded. Multicast routing now uses Multi-protocol BGP [RFC4760], the Multicast Source Discovery Protocol (MSDP) [RFC3618], and Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC2362], [RFC4601], especially the Source Specific Multicast (SSM) subset.
编者注：自最初编写此文件以来，多播路由又向前发展了。到2006年，BGMP已被有效取代。多播路由现在使用多协议BGP[RFC4760]、多播源发现协议（MSDP）[RFC3618]和协议独立多播稀疏模式（PIM-SM）[RFC2362]、[RFC4601]，尤其是源特定多播（SSM）子集。
This requires that a user be notified within a reasonable time period after persistent attempts, about inability to provide a service.
这要求在持续尝试后的合理时间内通知用户无法提供服务。
Relevance: Valid.
相关性：有效。
Current practice: There are ICMP messages for this; but, in many cases, they are not used, either because of fears about creating message storms or uncertainty about whether the end system can do anything useful with the resulting information. IPv6 implementations may be able to make better use of the information as they may have alternative addresses that could be used to exploit an alternative routing.
目前的做法是：有关于此的ICMP消息；但是，在许多情况下，它们并没有被使用，要么是因为担心会造成信息风暴，要么是因为不确定最终系统是否能利用产生的信息做任何有用的事情。IPv6实现可能能够更好地利用信息，因为它们可能具有可用于利用替代路由的替代地址。
The architecture was designed to accommodate the growth of the Internet.
该体系结构旨在适应互联网的发展。
Relevance: Valid. Properties of Internet topology might be an issue for future scalability (topology varies from very sparse to quite dense at present). Instead of setting out to accommodate growth in a specific time period, indefinite growth should be accommodated. On the other hand, such growth has to be accommodated without making the protocols too expensive -- trade-offs may be necessary.
相关性：有效。Internet拓扑的属性可能是未来可伸缩性的一个问题（目前拓扑从非常稀疏到非常密集）。应该适应无限增长，而不是着眼于适应特定时期的增长。另一方面，必须在不使协议过于昂贵的情况下适应这种增长——权衡可能是必要的。
Current practice: Scalability of the current protocols will not be sufficient under the current rate of growth. There are problems with BGP convergence for large dense topologies, problems with the slow speed of routing information propagation between routers in transit domains through the intra-domain protocol, for example, when a failure requires traffic to be redirected to an alternative exit point from the domain (see Section 5.9), limited support for hierarchy, etc.
当前实践：在当前的增长速度下，当前协议的可扩展性将是不够的。大型密集拓扑的BGP收敛存在问题，通过域内协议在传输域中的路由器之间的路由信息传播速度较慢，例如，当故障需要将流量重定向到域中的备用出口点时（参见第5.9节），对层次结构等的支持有限。
This requirement encapsulates the need for administrative domains ("Autonomous Systems" - AS) to be able to operate autonomously as regards setting routing policy:
该要求封装了管理域（“自治系统”-AS）在设置路由策略方面能够自主运行的需求：
Relevance: Valid. There may need to be additional requirements for adjusting policy decisions to the global functionality and for avoiding contradictory policies. This would decrease the possibility of unstable routing behavior.
相关性：有效。可能需要额外的要求来调整政策决策以适应全球功能，并避免相互矛盾的政策。这将减少不稳定路由行为的可能性。
There is a need for handling various degrees of trust in autonomous operations, ranging from no trust (e.g., between separate ISPs) to very high trust where the domains have a common goal of optimizing their mutual policies.
在自治操作中需要处理不同程度的信任，从不信任（例如，独立ISP之间）到非常高的信任，其中域有优化其相互策略的共同目标。
Policies for intra-domain operations should, in some cases, be revealed, using suitable abstractions.
在某些情况下，应该使用适当的抽象来揭示域内操作的策略。
Current practice: Policy management is in the control of network managers, as required, but there is little support for handling policies at an abstract level for a domain.
当前实践：策略管理由网络管理员根据需要进行控制，但对于在域的抽象级别上处理策略几乎没有支持。
Cooperating administrative entities decide about the extent of cooperation independently. This can lead to inconsistent, and potentially incompatible routing policies being applied in notionally cooperating domains. As discussed in Sections 5.2, 5.3, and 5.10, lack of coordination combined with global range of effects of BGP policies results in occasional disruption of Internet routing over an area far wider than the domains that are not cooperating effectively.
合作的行政实体独立决定合作的程度。这可能导致在概念上合作的域中应用不一致且可能不兼容的路由策略。如第5.2节、第5.3节和第5.10节所述，缺乏协调加上BGP政策的全球影响范围，会导致互联网路由在远比没有有效合作的领域更广的区域偶尔中断。
The routing environment is a distributed system. The distributed routing environment supports redundancy and diversity of nodes and links. Both the controlling rule sets, which implement the routing policies, and the places where operational control is applied, through decisions on path selection, are distributed (primarily in the routers).
路由环境是一个分布式系统。分布式路由环境支持节点和链路的冗余和多样性。实现路由策略的控制规则集和通过路径选择决策应用操作控制的位置都是分布式的（主要在路由器中）。
Relevance: Valid. RFC 1126 is very clear that we should not be using centralized solutions, but maybe we need a discussion on trade-offs between common knowledge and distribution (i.e., to allow for uniform policy routing, e.g., Global System for Mobile Communications (GSM) systems are in a sense centralized, but with hierarchies).
相关性：有效。RFC 1126非常清楚，我们不应该使用集中式解决方案，但我们可能需要讨论常识和分布之间的权衡（即，允许统一策略路由，例如，全球移动通信系统（GSM）系统在某种意义上是集中式的，但具有层次结构）。
Current practice: Routing is very distributed, but lacking the ability to consider optimization over several hops or domains.
当前的实践：路由非常分散，但缺乏考虑几个跳数或域优化的能力。
Editors' Note: Also, coordinating the implementation of a set of routing policies across a large domain with many routers running BGP is difficult. The policies have to be turned into BGP rules and applied individually to each router, giving opportunities for mismatch and error.
编者按：另外，在一个有许多路由器运行BGP的大域中协调一组路由策略的实施是困难的。这些策略必须转化为BGP规则，并分别应用于每个路由器，从而提供不匹配和错误的机会。
The routing environment and services should be based upon mechanisms and information that exhibit both integrity and security. That is, the routers should always be working with credible data derived through the reliable operation of protocols. Security from unwanted modification and influence is required.
路由环境和服务应基于同时显示完整性和安全性的机制和信息。也就是说，路由器应该始终使用通过可靠操作协议获得的可靠数据。需要防止不必要的修改和影响。
Relevance: Valid.
相关性：有效。
Current practice: BGP provides a limited mechanism for authentication and security of peering sessions, but this does not guarantee the authenticity or validity of the routing information that is exchanged.
当前做法：BGP为对等会话的身份验证和安全性提供了有限的机制，但这不能保证所交换的路由信息的真实性或有效性。
There are certainly security problems with the current practice. The Routing Protocol Security Requirements (rpsec) working group has been struggling to agree on a set of requirements for BGP security since early 2002.
目前的做法肯定存在安全问题。路由协议安全要求（rpsec）工作组自2002年初以来一直在努力就BGP安全的一系列要求达成一致。
Editors' Note: Proposals for authenticating BGP routing information using certificates were under development by the Secure Inter-Domain Routing (sidr) working group from 2006 through 2008.
编者按：安全域间路由（sidr）工作组从2006年到2008年正在制定使用证书验证BGP路由信息的建议。
This requires that the routing system provides adequate information on the state of the network to allow resource, problem, and fault management to be carried out effectively and expeditiously. The system must also provide controls that allow managers to use this information to make informed decisions and use it to control the operation of the routing system.
这要求路由系统提供有关网络状态的足够信息，以便有效、快速地进行资源、问题和故障管理。系统还必须提供控制，使管理人员能够利用这些信息做出明智的决策，并利用这些信息控制路由系统的运行。
Relevance: The requirement is reasonable, but we might need to be more specific on what information should be available, e.g., to prevent routing oscillations.
相关性：要求是合理的，但我们可能需要更具体地说明应该提供哪些信息，例如，防止路由振荡。
Current practice: All policies are determined locally, where they may appear reasonable but there is limited global coordination through the routing policy databases operated by the Internet registries (AfriNIC, APNIC, ARIN, LACNIC, RIPE, etc.).
当前做法：所有策略都是在本地确定的，这些策略可能看起来合理，但通过互联网注册中心（AfriNIC、APNIC、ARIN、LACNIC、RIME等）运营的路由策略数据库进行的全球协调有限。
Operators are not required to register their policies; even when policies are registered, it is difficult to check that the actual policies in use in other domains match the declared policies. Therefore, a manager cannot guarantee to design and implement policies that will interoperate with those of other domains to provide stable routing.
运营商无需注册其保单；即使注册了策略，也很难检查其他域中使用的实际策略是否与声明的策略匹配。因此，管理者不能保证设计和实施与其他域的策略互操作以提供稳定路由的策略。
Editors' Note: Operators report that management of BGP-based routing remains a function that needs highly-skilled operators and continual attention.
编者按：运营商报告说，基于BGP的路由管理仍然是一项需要高技能运营商和持续关注的功能。
Relevance: Valid. However, the paragraph states that assumptions on significant upgrades shouldn't be made. Although this is reasonable, a new architecture should perhaps be prepared to use upgrades when they occur.
相关性：有效。然而，该段指出，不应对重大升级进行假设。虽然这是合理的，但一个新的体系结构可能应该准备好在升级时使用升级。
Current practice: Most bandwidth is consumed by the exchange of the Network Layer Reachability Information (NLRI). Usage of processing cycles ("Central Processor Usage" - CPU) depends on the stability of the Internet. Both phenomena have a local nature, so there are not scaling problems with bandwidth and CPU usage. Instability of routing increases the consumption of resources in any case. The number of networks in the Internet dominates memory requirements -- this is a scaling problem.
目前的做法是：大部分带宽被网络层可达性信息（NLRI）的交换所消耗。处理周期的使用（“中央处理器使用”-CPU）取决于互联网的稳定性。这两种现象都具有局部性，因此不存在带宽和CPU使用的缩放问题。路由的不稳定性在任何情况下都会增加资源的消耗。互联网中的网络数量决定了内存需求——这是一个扩展问题。
Relevance: Valid. Should perhaps be stronger. Only providing a best-effort attempt may not be enough if real-time services are to be provided for. Detection of failures may need to be faster than 100 ms to avoid being noticed by end-users.
相关性：有效。也许应该更强大。如果要提供实时服务，仅提供尽力而为的尝试可能是不够的。故障检测可能需要快于100毫秒，以避免被最终用户注意到。
Current practice: Latency of fail-over is too high; sometimes minutes or longer.
当前做法：故障转移延迟太高；有时几分钟或更长。
Relevance: Valid. Loops should occur only with negligible probability and duration.
相关性：有效。循环发生的概率和持续时间应该可以忽略不计。
Current practice: Both link-state intra-domain routing and BGP inter-domain routing (if correctly configured) are forwarding-loop-free after having converged. However, convergence time for BGP can be very long, and poorly designed routing policies may result in a number of BGP speakers engaging in a cyclic pattern of advertisements and withdrawals that never converges to a stable result [RFC3345]. Part of the reason for long convergence times is
当前实践：链路状态域内路由和BGP域间路由（如果配置正确）在聚合后都是无转发循环的。然而，BGP的收敛时间可能非常长，设计不当的路由策略可能会导致许多BGP演讲者参与循环模式的广告和退出，而这些广告和退出永远不会收敛到稳定的结果[RFC3345]。收敛时间长的部分原因是
the non-locality of the effects of changes in BGP advertisements (see Section 5.3). Modifying the inter-domain routing protocol to make the effects of changes less global, and convergence a more local condition, might improve performance, assuming a suitable modification could be developed.
BGP广告变更影响的非局部性（见第5.3节）。假设可以进行适当的修改，修改域间路由协议以使更改的影响不那么全局，并使收敛成为更局部的条件，则可能会提高性能。
Relevance: Valid to some extent, but there is a trade-off between aggregation and immediate knowledge of reachability. It requires that routing tables contain enough information to determine that the destination is unknown or a path cannot be constructed to reach it.
相关性：在某种程度上是有效的，但在聚合和可达性的即时知识之间存在权衡。它要求路由表包含足够的信息，以确定目的地未知或无法构造到达目的地的路径。
Current practice: Knowledge about lost reachability propagates slowly through the networks due to slow convergence for route withdrawals.
当前实践：由于路由提取的收敛速度较慢，有关失去可达性的知识在网络中传播缓慢。
Relevance: Valid. Policy control of routing has become increasingly important as the Internet has turned into a business.
相关性：有效。随着互联网成为一种商业模式，路由策略控制变得越来越重要。
Current practice: Supported to some extent. Policies can only be applied locally in an AS and not globally. Policy information supplied has a very small probability of affecting policies in other ASs. Furthermore, only static policies are supported; between static policies and policies dependent upon volatile events of great celerity, there should exist events of which routing should be aware. Lastly, there is no support for policies other than route-properties (such as AS-origin, AS-path, destination prefix, Multi-Exit Discriminator-values (MED-values), etc).
目前的做法：在一定程度上得到支持。策略只能在AS中本地应用，而不能全局应用。提供的策略信息影响其他ASs中策略的概率非常小。此外，仅支持静态策略；在静态策略和依赖于快速易变事件的策略之间，应该存在路由应该知道的事件。最后，除了路由属性（如原点、as路径、目标前缀、多出口鉴别器值（MED值）等）之外，不支持其他策略。
Editors' Note: Subsequent to the original issue of this document, mechanisms that acknowledge the business relationships of operators have been developed such as the NOPEER community attribute [RFC3765]. However, the level of usage of this attribute is apparently not very great.
编者注：在本文件的原始版本之后，已经开发了确认运营商业务关系的机制，如NOPEER社区属性[RFC3765]。但是，该属性的使用级别显然不是很高。
Relevance: Valid to some extent, as they may conflict with the policies of the network administrator. It is likely that this requirement will be met by means of different bit-transport services offered by an operator, but at the cost of adequate provisioning, authentication, and policing when utilizing the service.
相关性：在某种程度上有效，因为它们可能与网络管理员的策略冲突。很可能通过运营商提供的不同比特传输服务来满足这一要求，但在使用该服务时需要充分的资源调配、身份验证和监管。
Current practice: Not supported in normal routing. Can be accomplished to some extent with loose source routing, resulting in inefficient forwarding in the routers. The various attempts to introduce Quality of Service (QoS -- e.g., Integrated Services and Differentiated Services (Diffserv)) can also be seen as means to support this requirement, but they have met with limited success in terms of providing alternate routes as opposed to providing improved service on the standard route.
当前做法：在正常路由中不受支持。在某种程度上可以通过松散源路由实现，从而导致路由器中的转发效率低下。引入服务质量（QoS——例如，集成服务和差异化服务（Diffserv））的各种尝试也可以被视为支持这一要求的手段，但它们在提供替代路由而不是在标准路由上提供改进的服务方面取得了有限的成功。
Editors' Note: From the standpoint of a later time, it would probably be more appropriate to say "total failure" rather than "limited success".
编者按：从以后的角度来看，说“完全失败”可能比说“有限成功”更合适。
3.1.2.1.6. "Provide paths which characterize user quality-of-service requirements"
3.1.2.1.6. “提供描述用户服务质量要求的路径”
Relevance: Valid to some extent, as they may conflict with the policies of the operator. It is likely that this requirement will be met by means of different bit-transport services offered by an operator, but at the cost of adequate provisioning, authentication, and policing when utilizing the service. It has become clear that offering to provide a particular QoS to any arbitrary destination from a particular source is generally impossible: QoS, except in very "soft" forms such as overall long-term average packet delay, is generally associated with connection-oriented routing.
相关性：在某种程度上有效，因为它们可能与运营商的政策冲突。很可能通过运营商提供的不同比特传输服务来满足这一要求，但在使用该服务时需要充分的资源调配、身份验证和监管。很明显，从特定来源向任意目的地提供特定的QoS通常是不可能的：QoS通常与面向连接的路由相关，除非是以非常“软”的形式，例如总体长期平均数据包延迟。
Current practice: Creating routes with specified QoS is not generally possible at present.
当前实践：目前通常不可能创建具有指定QoS的路由。
3.1.2.1.7. "Provide autonomy between inter- and intra-autonomous system route synthesis"
3.1.2.1.7. “提供自治系统间和自治系统内路由合成之间的自治”
Relevance: Inter- and intra-domain routing should stay independent, but one should notice that this, to some extent, contradicts the previous three requirements. There is a trade-off between abstraction and optimality.
相关性：域间和域内路由应该保持独立，但应该注意到，这在某种程度上与前面的三个要求相矛盾。在抽象性和优化性之间有一个权衡。
Current practice: Inter-domain routing is performed independently of intra-domain routing. Intra-domain routing is however, especially in transit domains, very interrelated with inter-domain routing.
当前实践：域间路由独立于域内路由执行。然而，域内路由与域间路由非常相关，特别是在传输域中。
3.1.2.2.1. "Decouple inter- and intra-autonomous system forwarding decisions"
3.1.2.2.1. “解耦自治系统间和自治系统内的转发决策”
Relevance: Valid.
相关性：有效。
Current practice: As explained in Section 3.1.2.1.7, intra-domain forwarding in transit domains is dependent on inter-domain forwarding decisions.
当前做法：如第3.1.2.1.7节所述，中转域中的域内转发取决于域间转发决策。
3.1.2.2.2. "Do not forward datagrams deemed administratively inappropriate"
3.1.2.2.2. “不要转发被视为管理不当的数据报”
Relevance: Valid, and increasingly important in the context of enforcing policies correctly expressed through routing advertisements but flouted by rogue peers that send traffic for which a route has not been advertised. On the other hand, packets that have been misrouted due to transient routing problems perhaps should be forwarded to reach the destination, although along an unexpected path.
相关性：在强制执行通过路由公告正确表达但被发送未公告路由的流量的流氓对等方藐视的策略方面，有效且日益重要。另一方面，由于暂时的路由问题而被错误路由的数据包可能应该被转发到目的地，尽管是沿着意外的路径。
Current practice: At stub domains (i.e., domains that do not provide any transit service for any other domains but that connect directly to one or more transit domains), there is packet filtering, e.g., to catch source address spoofing on outgoing traffic or to filter out unwanted incoming traffic. Filtering can in particular reject traffic (such as unauthorized transit traffic) that has been sent to a domain even when it has not advertised a route for such traffic on a given interface. The growing class of "middleboxes" (midboxes, e.g., Network Address
当前做法：在存根域（即，不为任何其他域提供任何传输服务但直接连接到一个或多个传输域的域），存在数据包过滤，例如，捕获传出流量上的源地址欺骗或过滤掉不需要的传入流量。过滤尤其可以拒绝已发送到域的流量（例如未经授权的传输流量），即使该域尚未在给定接口上公布此类流量的路由。越来越多的“中间盒”（中间盒，例如网络地址
Translators -- NATs) is quite likely to apply administrative rules that will prevent the forwarding of packets. Note that security policies may deliberately hide administrative denials. In the backbone, intentional packet dropping based on policies is not common.
Translators（NAT）很可能应用管理规则来阻止数据包的转发。请注意，安全策略可能故意隐藏管理拒绝。在主干网中，基于策略的有意丢包并不常见。
Relevance: Unclear, although it is clearly desirable to minimize the waste of forwarding resources by discarding datagrams that cannot be delivered at the earliest opportunity. There is a trade-off between scalability and keeping track of unreachable resources. The requirement effectively imposes a requirement on adjacent nodes to monitor for failures and take steps to cause rerouting at the earliest opportunity, if a failure is detected. However, packets that are already in-flight or queued on a failed link cannot generally be rescued.
相关性：不清楚，但通过丢弃无法尽早交付的数据报来最大限度地减少转发资源的浪费显然是可取的。在可伸缩性和跟踪无法访问的资源之间有一个权衡。该要求有效地要求相邻节点监控故障，并在检测到故障时尽早采取措施导致重新路由。但是，通常无法拯救已在传输中或在故障链路上排队的数据包。
Current practice: Routing protocols use both internal adjacency management sub-protocols (e.g., "hello" protocols) and information from equipment and lower-layer link watchdogs to keep track of failures in routers and connecting links. Failures will eventually result in the routing protocol reconfiguring the routing to avoid (if possible) a failed resource, but this is generally very slow (30s or more). In the meantime, datagrams may well be forwarded to failed resources. In general terms, end hosts and some non-router middleboxes do not participate in these notifications, and failures of such boxes will not affect the routing system.
当前实践：路由协议使用内部邻接管理子协议（例如，“hello”协议）和来自设备和下层链路监视器的信息来跟踪路由器和连接链路中的故障。故障最终将导致路由协议重新配置路由以避免（如果可能）出现故障的资源，但这通常非常缓慢（30秒或更长）。同时，数据报很可能被转发到发生故障的资源。一般来说，终端主机和一些非路由器中间盒不参与这些通知，这些中间盒的故障不会影响路由系统。
Relevance: Valid. This is necessary in enabling differentiation in the network, based on QoS, precedence, policy or security.
相关性：有效。这对于根据QoS、优先级、策略或安全性在网络中实现差异化是必要的。
Current practice: Ingress and egress filtering can be done based on policy. Some networks discriminate on the basis of requested QoS.
当前实践：可以根据策略进行入口和出口过滤。一些网络根据请求的QoS进行区分。
Relevance: Valid. However, an alternative arrangement of information bases, possibly with an element of centralization for the domain (as mentioned in Section 3.1.1.5) might offer some advantages through the ability to optimize across the domain and respond more quickly to changes and failures.
相关性：有效。然而，信息库的另一种安排，可能具有该领域的集中化元素（如第3.1.1.5节所述），可能通过跨领域优化和更快地响应变化和故障的能力提供一些优势。
Current practice: The information base is distributed, but it is unclear whether it supports all necessary routing functionality.
当前做法：信息库是分布式的，但不清楚它是否支持所有必要的路由功能。
Relevance: Valid. It should be possible to determine the availability and levels of availability of any resource (such as bandwidth) needed to carry out routing. This prevents needing to discover unavailability through failure. Resource location and discovery is arguably a separate concern that could be addressed outside the core routing requirements.
相关性：有效。应该能够确定执行路由所需的任何资源（如带宽）的可用性和可用性级别。这可以防止需要通过故障发现不可用性。资源定位和发现可以说是一个独立的问题，可以在核心路由需求之外解决。
Current practice: Resource availability is predominantly handled outside of the routing system.
当前实践：资源可用性主要在路由系统之外处理。
Relevance: Valid. However, certain requirements in the control plane, such as fast detection of faults may be worth consumption of more resources. Similarly, simplicity of implementation may make it cheaper to "back haul" traffic to central locations to minimize the cost of routing if bandwidth is cheaper than processing.
相关性：有效。但是，控制平面中的某些要求，例如快速检测故障，可能值得消耗更多资源。类似地，如果带宽比处理成本低，实现的简单性可能会使将流量“回程”到中心位置以最小化路由成本变得更便宜。
Current practice: BGP messages probably do not ordinarily consume excessive resources, but might during erroneous conditions. In the data plane, the nearly universal adoption of shortest-path protocols could be considered to result in minimization of transmission utilization.
当前实践：BGP消息通常可能不会消耗过多资源，但在错误情况下可能会消耗过多资源。在数据平面上，可以考虑几乎普遍采用最短路径协议，以使传输利用率最小化。
Relevance: Valid. But perhaps routing could be improved if certain information (especially policies) could be available either globally or at least for a wider-defined locality.
相关性：有效。但是，如果某些信息（特别是策略）可以在全球范围内或至少在更广泛的定义区域内可用，那么路由可能会得到改进。
Editors' Note: Limited information exchange would be potentially compatible with a more local form of convergence than BGP tries to achieve today. Limited information exchange is potentially incompatible with global convergence.
编者按：有限的信息交流可能会与BGP今天试图实现的更本地化的融合形式兼容。有限的信息交换可能与全球趋同不兼容。
Current practice: Policies are used to determine which reachability information is exported, but neighbors receiving the information are not generally aware of the policies that resulted in this export.
当前做法：策略用于确定导出哪些可达性信息，但接收信息的邻居通常不知道导致此导出的策略。
Relevance: Valid, but routing system should, perhaps, not be limited to this exclusively.
相关性：有效，但路由系统可能不应仅限于此。
Current practice: Supported.
目前的做法：支持。
3.1.2.4.2. "Accommodate a connection-less oriented user transport service"
3.1.2.4.2. “提供面向连接较少的用户传输服务”
Relevance: Valid, but routing system should, perhaps, not be limited to this exclusively.
相关性：有效，但路由系统可能不应仅限于此。
Current practice: Accommodated.
目前的做法：适应。
Relevance: No longer valid. Needs to be increased -- potentially indefinitely. It is extremely difficult to foresee the future size expansion of the Internet, so the Utopian solution would be to achieve an Internet whose architecture is scale invariant. Regrettably, this may not be achievable without introducing undesirable complexity and a suitable trade-off between complexity and scalability is likely to be necessary.
相关性：不再有效。需要增加——可能是无限期的。很难预见互联网未来的规模扩张，因此乌托邦式的解决方案将是实现一个架构不随规模变化的互联网。遗憾的是，如果不引入不希望的复杂性，这可能无法实现，并且可能需要在复杂性和可伸缩性之间进行适当的权衡。
Current Practice: Supported, but perhaps reaching its limit. Since the original version of this document was written in 2001, the number of ASs advertised has grown from around 8000 to 20000, and almost 35000 AS numbers have been allocated by the regional registries [Huston05]. If this growth continues, the original 16-bit AS space in BGP-4 will be exhausted in less than 5 years. Planning for an extended AS space is now an urgent requirement.
目前的做法：支持，但可能已达到极限。自本文件的原始版本于2001年编写以来，所宣传的ASs数量已从8000个左右增加到20000个，并且由于区域登记处已分配了近35000个数量[Huston05]。如果这种增长继续下去，BGP-4中原有的16位AS空间将在不到5年的时间内耗尽。现在迫切需要规划扩展AS空间。
Editors' Note: At the time of publication, 32- bit AS numbers have been introduced and are being deployed.
编者注：在本书出版时，32位AS编号已经引入并正在部署中。
Relevance: Valid. However, perhaps not all interconnections should be accessible globally.
相关性：有效。然而，也许并非所有的互连都应该在全球范围内实现。
Current practice: BGP-4 allows for arbitrary interconnections.
当前做法：BGP-4允许任意互连。
Relevance: Valid, as stated before. It might be acceptable for a more complex service to take longer to deliver, but it still has to meet the application's requirements -- routing has to be at the service of the end-to-end principle.
相关性：如前所述，有效。更复杂的服务可能需要更长的时间才能交付，但它仍然必须满足应用程序的要求——路由必须以端到端原则为服务。
Editors' Note: Delays in setting up connections due to network functions such as NAT boxes are becoming increasingly problematic. The routing system should try to keep any routing delay to a minimum.
编者按：由于网络功能（如NAT盒）造成的连接设置延迟问题越来越严重。路由系统应尽量将任何路由延迟保持在最小。
Current practice: More or less, with the exception of convergence and fault robustness.
目前的做法：或多或少，除了收敛性和故障鲁棒性。
Relevance: Valid.
相关性：有效。
Current practice: Systems with limited resources are typically stub domains that advertise very little information.
当前做法：资源有限的系统通常是发布很少信息的存根域。
3.1.2.5.3. "Minimize impact of dissimilarities between autonomous systems"
3.1.2.5.3. “最小化自治系统之间差异的影响”
Relevance: Important. This requirement is critical to a future architecture. In a domain-based routing environment where the internal properties of domains may differ radically, it will be important to be sure that these dissimilarities are minimized at the borders.
相关性：重要。这一需求对于未来的体系结构至关重要。在基于域的路由环境中，域的内部属性可能存在根本性差异，确保这些差异在边界处最小化是很重要的。
Current: practice: For the most part, this capability is not really required in today's networks since the intra-domain attributes are broadly similar across domains.
当前：实践：在大多数情况下，这种功能在当今的网络中并不是真正需要的，因为域内属性在各个域之间大致相似。
3.1.2.5.4. "Accommodate the addressing schemes and protocol mechanisms of the autonomous systems"
3.1.2.5.4. “适应自治系统的寻址方案和协议机制”
Relevance: Important, probably more so than when RFC 1126 was originally developed because of the potential deployment of IPv6, wider usage of MPLS, and the increasing usage of VPNs.
相关性：重要的是，由于IPv6的潜在部署、MPLS的更广泛使用以及VPN的日益增加，可能比RFC1126最初开发时更重要。
Current practice: Only one global addressing scheme is supported in most autonomous systems, but the availability of IPv6 services is steadily increasing. Some global backbones support IPv6 routing and forwarding.
当前做法：大多数自治系统只支持一种全局寻址方案，但IPv6服务的可用性正在稳步增加。一些全局主干网支持IPv6路由和转发。
Relevance: Valid, but note that what can be implemented today is different from what was possible when RFC 1126 was written: a future domain-based routing architecture should not be unreasonably constrained by past limitations.
相关性：有效，但请注意，今天可以实现的与编写RFC1126时可能实现的不同：未来基于域的路由体系结构不应受到过去限制的不合理约束。
Current practice: BGP was implemented and meets a large proportion of the original requirements.
当前做法：实施了BGP，满足了大部分原始要求。
RFC 1126 also included a section discussing non-goals. This section discusses the extent to which these are still non-goals. It also considers whether the fact that they were non-goals adversely affects today's IDR system.
RFC1126还包括一节讨论非目标。本节将讨论这些目标在多大程度上仍然是非目标。它还考虑了非目标这一事实是否会对当今的IDR系统产生不利影响。
The authors of RFC 1126 were explicitly saying that IP and its inter-domain routing system need not be deployed in every AS, and a participant should not necessarily expect to be able to reach a given AS, possibly because of routing policies. In a sense, this "non-goal" has effectively been achieved by the Internet and IP protocols. This requirement reflects a different worldview where there was serious competition for network protocols, which is really no longer the case. Ubiquitous deployment of inter-domain routing in particular has been achieved and must not be undone by any proposed future domain-based routing architecture. On the other hand:
RFC1126的作者明确表示，IP及其域间路由系统不需要部署在每个AS中，参与者不一定期望能够到达给定的AS，可能是因为路由策略。从某种意义上说，互联网和IP协议有效地实现了这一“非目标”。这一要求反映了一种不同的世界观，在这种世界观中，对网络协议存在着严重的竞争，但事实上已经不是这样了。特别是域间路由的无处不在的部署已经实现，任何未来提出的基于域的路由架构都不能撤销。另一方面：
o ubiquitous connectivity cannot be reached in a policy-sensitive environment and should not be an aim.
o 在政策敏感的环境中无法实现无处不在的连通性，因此不应将其作为目标。
Editors' Note: It has been pointed out that this statement could be interpreted as being contrary to the Internet mission of providing universal connectivity. The fact that limits to connectivity will be added as operational requirements in a policy-sensitive environment should not imply that a future domain-based routing architecture contains intrinsic limits on connectivity.
编者按：有人指出，这一说法可能会被解释为与提供通用连接的互联网使命背道而驰。连接限制将作为策略敏感环境中的操作要求添加，这一事实不应意味着未来基于域的路由体系结构包含连接的固有限制。
o it must not be required that the same routing mechanisms are used throughout, provided that they can interoperate appropriately.
o 如果可以适当地进行互操作，则不需要在整个过程中使用相同的路由机制。
o the information needed to control routing in a part of the network should not necessarily be ubiquitously available, and it must be possible for an operator to hide commercially sensitive information that is not needed outside a domain.
o 控制网络某一部分路由所需的信息不一定无处不在，运营商必须能够隐藏域外不需要的商业敏感信息。
o the introduction of IPv6 reintroduces an element of diversity into the world of network protocols, but the similarities of IPv4 and IPv6 as regards routing and forwarding make this event less likely to drive an immediate diversification in routing systems. The potential for further growth in the size of the network enabled by IPv6 is very likely to require changes in the future: whether this results in the replacement of one de facto ubiquitous system with another remains to be seen but cannot be a requirement -- it will have to interoperate with BGP during the transition.
o IPv6的引入将多样性元素重新引入网络协议领域，但IPv4和IPv6在路由和转发方面的相似性使得这一事件不太可能立即推动路由系统的多样化。IPv6所支持的网络规模的进一步增长的潜力在未来很可能需要改变：这是否会导致一个事实上无处不在的系统被另一个系统所取代还有待观察，但这不是一个要求——它必须在过渡期间与BGP互操作。
Relevance: De facto essential for a future domain-based routing architecture, but what is required is ubiquity of the routing system rather than ubiquity of connectivity and it must be capable of a gradual takeover through interoperation with the existing system.
相关性：事实上，对于未来基于域的路由体系结构至关重要，但需要的是路由系统的普遍性，而不是连接的普遍性，并且必须能够通过与现有系统的互操作逐步接管。
Current practice: De facto ubiquity achieved.
目前的做法：实现了事实上的普遍性。
Relevance: It is not clear if this non-goal was to be applied to routing or forwarding. It is definitely a non-goal to adapt the choice of route when there is transient congestion. However, to add support for congestion avoidance (e.g., Explicit Congestion Notification (ECN) and ICMP messages) in the forwarding process would be a useful addition. There is also extensive work going on in traffic engineering that should result in congestion avoidance through routing as well as in forwarding.
相关性：不清楚这一非目标是否适用于路由或转发。当存在暂时性拥挤时，调整路线选择绝对不是目标。然而，在转发过程中添加对拥塞避免的支持（例如，显式拥塞通知（ECN）和ICMP消息）将是一个有用的补充。在流量工程方面也有大量的工作正在进行，这些工作将通过路由和转发避免拥塞。
Current practice: Some ICMP messages (e.g., source quench) exist to deal with congestion control, but these are not generally used as they either make the problem worse or there is no mechanism to reflect the message into the application that is providing the source.
当前做法：存在一些ICMP消息（例如，源猝灭）来处理拥塞控制，但通常不使用这些消息，因为它们会使问题恶化，或者没有机制将消息反映到提供源的应用程序中。
Relevance: This should neither be a non-goal nor an explicit goal. It might be desirable in some cases and should be considered as an optional architectural feature.
相关性：这既不是一个非目标，也不是一个明确的目标。在某些情况下，它可能是可取的，并且应该被视为可选的体系结构特征。
Current practice: Can be implemented by exporting different prefixes on different links, but this requires manual configuration and does not consider actual load.
当前的实践：可以通过在不同的链接上导出不同的前缀来实现，但是这需要手动配置，并且不考虑实际负载。
Editors' Note: This configuration is carried out extensively as of 2006 and has been a significant factor in routing table bloat. If this need is a real operational requirement, as it seems to be for multi-homed or otherwise richly connected sites, it will be necessary to reclassify this as a real and important goal.
编者注：这种配置从2006年开始广泛实施，并且一直是路由表膨胀的一个重要因素。如果这一需求是一个实际的操作需求，就像多址或其他连接丰富的站点一样，那么有必要将其重新分类为一个真正重要的目标。
Relevance: Valid. Cost-efficiency should be striven for; we note that maximizing resource utilization does not always lead to the greatest cost-efficiency.
相关性：有效。努力提高成本效益；我们注意到，最大化资源利用率并不总是带来最大的成本效益。
Current practice: Not currently part of the system, though often a "hacked in" feature done with manual configuration.
当前做法：目前不是系统的一部分，但通常是通过手动配置完成的“入侵”功能。
This non-goal was put in place to ensure that the IDR did not have to meet real-time deadline goals such as might apply to Constant Bit Rate (CBR) real-time services in ATM.
这一非目标是为了确保IDR不必满足实时截止日期目标，如ATM中可能适用于恒定比特率（CBR）实时服务的目标。
Relevance: The hard form of deadline services is still a non-goal for the future domain-based routing architecture, but overall delay bounds are much more of the essence than was the case when RFC 1126 was written.
相关性：截止日期服务的硬形式对于未来基于域的路由体系结构来说仍然不是一个目标，但是总体延迟边界比编写RFC1126时更为重要。
Current practice: Service providers are now offering overall probabilistic delay bounds on traffic contracts. To implement these contracts, there is a requirement for a rather looser form of delay sensitive routing.
目前的做法是：服务提供商现在为流量合同提供总体概率延迟限制。为了实现这些契约，需要一种更宽松的延迟敏感路由形式。
The requirement in RFC 1126 is somewhat opaque, but appears to imply that what we would today call QoS routing is a non-goal and that routing would not seek to control the elastic characteristics of Internet traffic whereby a TCP connection can seek to utilize all the spare bandwidth on a route, possibly to the detriment of other connections sharing the route or crossing it.
RFC 1126中的要求有些不透明，但似乎暗示我们今天所称的QoS路由是一个非目标，路由不会试图控制Internet流量的弹性特征，TCP连接可以利用路由上的所有空闲带宽，可能会损害共享路线或穿越路线的其他连接。
Relevance: Open Issue. It is not clear whether dynamic QoS routing can or should be implemented. Such a system would seek to control the admission and routing of traffic depending on current or recent resource utilization. This would be particularly problematic where traffic crosses an ownership boundary because of the need for potentially commercially sensitive information to be made available outside the ownership boundary.
相关性：未决问题。目前尚不清楚是否可以或应该实施动态QoS路由。这种系统将寻求根据当前或最近的资源利用率来控制流量的接纳和路由。由于需要在所有权边界之外提供潜在的商业敏感信息，因此当流量跨越所有权边界时，这将特别成问题。
Current practice: Routing does not consider dynamic resource availability. Forwarding can support service differentiation.
当前的实践：路由不考虑动态资源可用性。转发可以支持服务差异化。
During the decade before the widespread success of the World Wide Web, ISO was developing the communications architecture and protocol suite Open Systems Interconnection (OSI). For a considerable part of this time, OSI was seen as a possible competitor for and even a replacement for the IP suite as this basis for the Internet. The technical developments of the two protocols were quite heavily interrelated with each providing ideas and even components that were adapted into the other suite.
在万维网广泛成功之前的十年间，ISO正在开发通信体系结构和协议套件开放系统互连（OSI）。在相当长的一段时间里，OSI被视为作为互联网基础的IP套件的可能竞争对手，甚至是替代者。这两个协议的技术发展是非常密切相关的，每一个协议都提供了思想，甚至是被改编成另一套协议的组件。
During the early stages of the development of OSI, the IP suite was still mainly in use on the ARPANET and the relatively small scale first phase NSFNET. This was effectively a single administrative domain with a simple tree-structured network in a three-level hierarchy connected to a single logical exchange point (the NSFNET backbone). In the second half of the 1980s, the NSFNET was starting on the growth and transformation that would lead to today's Internet. It was becoming clear that the backbone routing protocol, the Exterior Gateway Protocol (EGP) [RFC0904], was not going to cope even with the limited expansion being planned. EGP is an "all informed" protocol that needed to know the identities of all gateways, and this was no longer reasonable. With the increasing complexity of the NSFNET and the linkage of the NSFNET network to other networks, there was a desire for policy-based routing that would allow administrators to manage the flow of packets between networks. The first version of the Border Gateway Protocol (BGP-1) [RFC1105] was developed as a replacement for EGP with policy capabilities -- a stopgap EGP version 3 had been created as an interim measure while BGP was developed. BGP was designed to work on a hierarchically structured network, such as the original NSFNET, but could also work on networks that were at least partially non-hierarchical where there were links between ASs at the same level in the hierarchy (we would now call these "peering arrangements") although the protocol made a distinction between different kinds of links (links are classified as upwards, downwards, or sideways). ASs themselves were a "fix" for the complexity that developed in the three-tier structure of the NSFNET.
在OSI开发的早期阶段，IP套件仍然主要用于ARPANET和规模相对较小的第一阶段NSFNET。这实际上是一个单一的管理域，具有一个简单的树状结构网络，在三级层次结构中连接到单个逻辑交换点（NSFNET主干）。在20世纪80年代后半期，NSFNET开始了增长和转型，这将导致今天的互联网。很明显，主干路由协议，外部网关协议（EGP）[RFC0904]，即使是计划中的有限扩展也无法应对。EGP是一种“全信息”协议，需要知道所有网关的身份，这已不再合理。随着NSFNET的日益复杂以及NSFNET网络与其他网络的连接，人们希望基于策略的路由能够允许管理员管理网络之间的数据包流。边境网关协议（BGP-1）[RFC1105]的第一个版本是作为具有政策能力的EGP的替代品开发的——在BGP开发期间，作为临时措施创建了临时EGP版本3。BGP设计用于层次结构的网络，如原始NSFNET，但也可以用于至少部分非层次结构的网络，其中ASs之间在层次结构的同一级别存在链接（我们现在称这些为“对等安排”）尽管协议对不同类型的链接进行了区分（链接分为向上、向下或侧向）。ASs本身是对NSFNET三层结构中形成的复杂性的“修复”。
Meanwhile, the OSI architects, led by Lyman Chapin, were developing a much more general architecture for large-scale networks. They had recognized that no one node, especially an end-system (host), could or should attempt to remember routes from "here" to "anywhere" -- this sounds obvious today, but was not so obvious 20 years ago. They were also considering hierarchical networks with independently
与此同时，由Lyman Chapin领导的OSI架构师正在为大规模网络开发更通用的体系结构。他们已经认识到，没有一个节点，特别是终端系统（主机），能够或应该尝试记住从“这里”到“任何地方”的路由——这在今天听起来很明显，但在20年前就不那么明显了。他们也在考虑独立的分层网络
administered domains -- a model already well entrenched in the public-switched telephone network. This led to a vision of a network with multiple independent administrative domains with an arbitrary interconnection graph and a hierarchy of routing functionality. This architecture was fairly well established by 1987 [Tsuchiya87]. The architecture initially envisaged a three-level routing functionality hierarchy in which each layer had significantly different characteristics:
管理域——一种已经在公共交换电话网络中根深蒂固的模式。这导致了一个网络的愿景，即具有多个独立的管理域，具有任意的互连图和路由功能的层次结构。这种建筑在1987年已经相当完善[Tsuchiya87]。该体系结构最初设想了三级路由功能层次结构，其中每一层具有显著不同的特征：
1. *End-system to intermediate system (IS) routing (host to router)*, in which the principal functions are discovery and redirection.
1. *终端系统到中间系统（IS）路由（主机到路由器）*，其中主要功能是发现和重定向。
2. *Intra-domain IS-IS routing (router to router)*, in which "best" routes between end-systems in a single administrative domain are computed and used. A single algorithm and routing protocol would be used throughout any one domain.
2. *域内IS-IS路由（路由器到路由器）*，其中计算并使用单个管理域中终端系统之间的“最佳”路由。单一算法和路由协议将在任何一个域中使用。
3. *Inter-domain IS-IS routing (router to router)*, in which routes between routing domains within administrative domains are computed (routing is considered separately between administrative domains and routing domains).
3. *域间IS-IS路由（路由器到路由器）*，其中计算管理域内路由域之间的路由（在管理域和路由域之间单独考虑路由）。
Level 3 of this hierarchy was still somewhat fuzzy. Tsuchiya says:
这个层次结构的第三级仍然有些模糊。筑屋说：
The last two components, Inter-Domain and Inter-Administration routing, are less clear-cut. It is not obvious what should be standardized with respect to these two components of routing. For example, for Inter-Domain routing, what can be expected from the Domains? By asking Domains to provide some kind of external behavior, we limit their autonomy. If we expect nothing of their external behavior, then routing functionality will be minimal.
最后两个组成部分，域间和管理间路由，则不那么明确。关于路由的这两个组成部分，什么应该标准化并不明显。例如，对于域间路由，可以从域中获得什么？通过要求域提供某种外部行为，我们限制了它们的自治性。如果我们对它们的外部行为没有任何期望，那么路由功能将是最小的。
Across administrations, it is not known how much trust there will be. In fact, the definition of trust itself can only be determined by the two or more administrations involved.
各届政府之间的信任程度不得而知。事实上，信托本身的定义只能由两个或两个以上的政府来确定。
Fundamentally, the problem with Inter-Domain and Inter-Administration routing is that autonomy and mistrust are both antithetical to routing. Accomplishing either will involve a number of tradeoffs which will require more knowledge about the environments within which they will operate.
从根本上讲，域间和管理间路由的问题在于自治和不信任都与路由相反。实现这两个目标都需要进行大量权衡，这需要更多地了解它们将在其中运行的环境。
Further refinement of the model occurred over the next couple of years and a more fully formed view is given by Huitema and Dabbous in 1989 [Huitema90]. By this stage, work on the original IS-IS link-state protocol, originated by the Digital Equipment Corporation (DEC), was fairly advanced and was close to becoming a Draft
在接下来的几年里，模型得到了进一步的完善，Huitema和Dabbous在1989年给出了更完整的观点[Huitema90]。到了这个阶段，由数字设备公司（DEC）发起的原始IS-IS链路状态协议的工作已经相当先进，并即将成为草案
International Standard. IS-IS is of course a major component of intra-domain routing today and inspired the development of the Open Shortest Path First (OSPF) family. However, Huitema and Dabbous were not able to give any indication of protocol work for Level 3. There are hints of possible use of centralized route servers.
国际标准。IS-IS当然是当今域内路由的主要组成部分，并激发了开放最短路径优先（OSPF）系列的发展。然而，Huitema和Dabbous未能给出任何3级协议工作的指示。有迹象表明可能使用集中式路由服务器。
In the meantime, the NSFNET consortium and the IETF had been struggling with the rapid growth of the NSFNET. It had been clear since fairly early on that EGP was not suitable for handling the expanding network and the race was on to find a replacement. There had been some intent to include a metric in EGP to facilitate routing decisions, but no agreement could be reached on how to define the metric. The lack of trust was seen as one of the main reasons that EGP could not establish a globally acceptable routing metric: again this seems to be a clearly futile aim from this distance in time! Consequently, EGP became effectively a rudimentary path-vector protocol that linked gateways with Autonomous Systems. It was totally reliant on the tree-structured network to avoid routing loops, and the all-informed nature of EGP meant that update packets became very large. BGP version 1 [RFC1105] was standardized in 1989, but it had been in development for some time before this and had already seen action in production networks prior to standardization. BGP was the first real path-vector routing protocol and was intended to relieve some of the scaling problems as well as providing policy-based routing. Routes were described as paths along a "vector" of ASs without any associated cost metric. This way of describing routes was explicitly intended to allow detection of routing loops. It was assumed that the intra-domain routing system was loop-free with the implication that the total routing system would be loop-free if there were no loops in the AS path. Note that there were no theoretical underpinnings for this work, and it traded freedom from routing loops for guaranteed convergence.
与此同时，NSFNET联盟和IETF一直在努力应对NSFNET的快速增长。很早以前就很清楚，EGP不适合处理不断扩大的网络，现在正在寻找替代者。有人打算在专家组方案中列入一项指标，以促进路由决策，但未能就如何定义该指标达成一致意见。缺乏信任被视为EGP无法建立一个全球可接受的路由度量的主要原因之一：从时间上看，这显然是一个徒劳的目标！因此，EGP有效地成为连接网关和自治系统的基本路径向量协议。它完全依赖于树状结构的网络来避免路由循环，而EGP的全信息特性意味着更新包变得非常大。BGP版本1[RFC1105]于1989年标准化，但在此之前它已经开发了一段时间，并且在标准化之前已经在生产网络中看到了行动。BGP是第一个真正的路径向量路由协议，旨在缓解一些扩展问题，并提供基于策略的路由。路径被描述为沿着ASs的“向量”的路径，没有任何相关的成本度量。这种描述路由的方式明确地旨在允许检测路由循环。假设域内路由系统是无环的，这意味着如果AS路径中没有环，则整个路由系统将是无环的。请注意，这项工作没有任何理论基础，它用路由循环的自由度换取了保证的收敛性。
Also, the NSFNET was a government-funded research and education network. Commercial companies that were partners in some of the projects were using the NSFNET for their research activities, but it was becoming clear that these companies also needed networks for commercial traffic. NSFNET had put in place "acceptable use" policies that were intended to limit the use of the network. However, there was little or no technology to support the legal framework.
此外，NSFNET是一个政府资助的研究和教育网络。在一些项目中作为合作伙伴的商业公司正在使用NSFNET进行研究活动，但越来越清楚的是，这些公司也需要用于商业流量的网络。NSFNET制定了旨在限制网络使用的“可接受使用”政策。然而，支持法律框架的技术很少或根本没有。
Practical experience, IETF IAB discussion (centered in the Internet Architecture Task Force) and the OSI theoretical work were by now coming to the same conclusions:
实践经验、IETF IAB讨论（以互联网体系结构任务组为中心）和OSI理论工作现在得出了相同的结论：
o Networks were going to be composed out of multiple administrative domains (the federated network),
o 网络将由多个管理域（联邦网络）组成，
o The connections between these domains would be an arbitrary graph and certainly not a tree,
o 这些域之间的连接将是一个任意图，当然不是一棵树，
o The administrative domains would wish to establish distinctive, independent routing policies through the graph of Autonomous Systems, and
o 管理域希望通过自治系统图建立独特、独立的路由策略，以及
o Administrative domains would have a degree of distrust of each other that would mean that policies would remain opaque.
o 管理域之间会有一定程度的互不信任，这意味着政策将保持不透明。
These views were reflected by Susan Hares' (working for Merit Networks at that time) contribution to the Internet Architecture (INARC) workshop in 1989, summarized in the report of the workshop [INARC89]:
这些观点反映在Susan Hares（当时为卓越网络工作）对1989年互联网体系结构（INARC）研讨会的贡献中，总结在研讨会报告[INARC89]中：
The rich interconnectivity within the Internet causes routing problems today. However, the presenter believes the problem is not the high degree of interconnection, but the routing protocols and models upon which these protocols are based. Rich interconnectivity can provide redundancy which can help packets moving even through periods of outages. Our model of interdomain routing needs to change. The model of autonomous confederations and autonomous systems [RFC0975] no longer fits the reality of many regional networks. The ISO models of administrative domain and routing domains better fit the current Internet's routing structure.
互联网内部丰富的互联性导致了今天的路由问题。然而，演示者认为问题不在于高度互连，而在于这些协议所基于的路由协议和模型。丰富的互连性可以提供冗余，这有助于数据包在停机期间移动。我们的域间路由模型需要改变。自治联盟和自治系统的模型[RFC0975]不再适合许多地区网络的现实。管理域和路由域的ISO模型更适合当前Internet的路由结构。
With the first NSFNET backbone, NSF assumed that the Internet would be used as a production network for research traffic. We cannot stop these networks for a month and install all new routing protocols. The Internet will need to evolve its changes to networking protocols while still continuing to serve its users. This reality colors how plans are made to change routing protocols.
有了第一个NSFNET主干网，NSF假设互联网将被用作研究流量的生产网络。我们不能在一个月内停止这些网络并安装所有新的路由协议。互联网将需要在继续为用户服务的同时，不断改变其网络协议。这一现实改变了改变路由协议的计划。
It is also interesting to note that the difficulties of organizing a transition were recognized at this stage and have not been seriously explored or resolved since.
还值得注意的是，在这一阶段，人们认识到了组织过渡的困难，但此后没有认真探讨或解决这些困难。
Policies would primarily be interested in controlling which traffic should be allowed to transit a domain (to satisfy commercial constraints or acceptable use policies), thereby controlling which traffic uses the resources of the domain. The solution adopted by both the IETF and OSI was a form of distance vector hop-by-hop routing with explicit policy terms. The reasoning for this choice can be found in Breslau and Estrin's 1990 paper [Breslau90] (implicitly -- because some other alternatives are given such as a link state with policy suggestion, which, with hindsight, would have
策略主要关注于控制应允许哪些流量通过域（以满足商业约束或可接受的使用策略），从而控制哪些流量使用域的资源。IETF和OSI采用的解决方案是一种距离向量逐跳路由形式，带有明确的策略术语。这一选择的理由可以在Breslau和Estrin 1990年的论文[Breslau90]中找到（含蓄地——因为给出了一些其他替代方案，如与政策建议挂钩的州，事后看来，这可能会有帮助）
even greater problems than BGP on a global scale network). Traditional distance-vector protocols exchanged routing information in the form of a destination and a metric. The new protocols explicitly associated policy expressions with the route by including either a list of the source ASs that are permitted to use the route described in the routing update, and/or a list of all ASs traversed along the advertised route.
甚至比全球规模网络上的BGP更大的问题）。传统的距离向量协议以目的地和度量的形式交换路由信息。新协议通过包括允许使用路由更新中描述的路由的源ASs列表和/或沿公布路由遍历的所有ASs列表，显式地将策略表达式与路由关联。
Parallel protocol developments were already in progress by the time this paper was published: BGP version 2 [RFC1163] in the IETF and the Inter-Domain Routing Protocol (IDRP) [ISO10747], which would be the Level 3 routing protocol for the OSI architecture. IDRP was developed under the aegis of the ANSI XS3.3 working group led by Lyman Chapin and Charles Kunzinger. The two protocols were very similar in basic design, but IDRP has some extra features, some of which have been incorporated into later versions of BGP; others may yet be so, and still others may be seen to be inappropriate. Breslau and Estrin summarize the design of IDRP as follows:
在本文发表时，并行协议的开发已经在进行中：IETF中的BGP版本2[RFC1163]和域间路由协议（IDRP）[ISO10747]，这将是OSI体系结构的3级路由协议。IDRP是在Lyman Chapin和Charles Kunzinger领导的ANSI XS3.3工作组的支持下开发的。这两个协议在基本设计上非常相似，但IDRP有一些额外的功能，其中一些已被并入BGP的更高版本中；还有一些可能是这样，还有一些可能被认为是不合适的。Breslau和Estrin将IDRP的设计总结如下：
IDRP attempts to solve the looping and convergence problems inherent in distance vector routing by including full AD (Administrative Domain -- essentially the equivalent of what are now called ASs) path information in routing updates. Each routing update includes the set of ADs that must be traversed in order to reach the specified destination. In this way, routes that contain AD loops can be avoided.
IDRP试图通过在路由更新中包含完整的AD（管理域——本质上相当于现在所谓的ASs）路径信息来解决距离向量路由中固有的循环和收敛问题。每个路由更新都包括一组ADs，这些ADs必须经过这些ADs才能到达指定的目的地。这样，可以避免包含AD循环的路由。
IDRP updates also contain additional information relevant to policy constraints. For instance, these updates can specify what other ADs are allowed to receive the information described in the update. In this way, IDRP is able to express source specific policies. The IDRP protocol also provides the structure for the addition of other types of policy related information in routing updates. For example, User Class Identifiers (UCI) could also be included as policy attributes in routing updates.
IDRP更新还包含与策略约束相关的附加信息。例如，这些更新可以指定允许哪些其他广告接收更新中描述的信息。这样，IDRP就能够表达特定于源代码的策略。IDRP协议还提供了在路由更新中添加其他类型的策略相关信息的结构。例如，用户类标识符（UCI）也可以作为策略属性包含在路由更新中。
Using the policy route attributes IDRP provides the framework for expressing more fine grained policy in routing decisions. However, because it uses hop-by-hop distance vector routing, it only allows a single route to each destination per-QOS to be advertised. As the policy attributes associated with routes become more fine grained, advertised routes will be applicable to fewer sources. This implies a need for multiple routes to be advertised for each destination in order to increase the probability that sources have acceptable routes available to them. This effectively replicates the routing table per forwarding entity for each QoS, UCI, source combination that might appear in
使用策略路由属性IDRP提供了在路由决策中表达更细粒度策略的框架。然而，因为它使用逐跳距离向量路由，所以它只允许每个QOS到每个目的地的单个路由被公布。随着与路由关联的策略属性变得更细粒度，播发的路由将适用于更少的源。这意味着需要为每个目的地通告多条路由，以增加源具有可接受路由的可能性。这可以有效地复制每个转发实体中可能出现的每个QoS、UCI和源组合的路由表
a packet. Consequently, we claim that this approach does not scale well as policies become more fine grained, i.e., source or UCI specific policies.
一包。因此，我们声称这种方法不能很好地扩展，因为策略变得更细粒度，即源或UCI特定的策略。
Over the next three or four years, successive versions of BGP (BGP-2 [RFC1163], BGP-3 [RFC1267], and BGP-4 [RFC1771]) were deployed to cope with the growing and by now commercialized Internet. From BGP-2 onwards, BGP made no assumptions about an overall structure of interconnections allowing it to cope with today's dense web of interconnections between ASs. BGP version 4 was developed to handle the change from classful to classless addressing. For most of this time, IDRP was being developed in parallel, and both protocols were implemented in the Merit gatedaemon routing protocol suite. During this time, there was a movement within the IETF that saw BGP as a stopgap measure to be used until the more sophisticated IDRP could be adapted to run over IP instead of the OSI connectionless protocol Connectionless Network Protocol (CLNP). However, unlike its intra-domain counterpart IS-IS, which has stood the test of time, and indeed proved to be more flexible than OSPF, IDRP was ultimately not adopted by the market. By the time the NSFNET backbone was decommissioned in 1995, BGP-4 was the inter-domain routing protocol of choice and OSI's star was already beginning to wane. IDRP is now little remembered.
在接下来的三四年中，BGP的连续版本（BGP-2[RFC1163]、BGP-3[RFC1267]和BGP-4[RFC1771]）被部署，以应对不断增长且现已商业化的互联网。从BGP-2开始，BGP没有对互连的总体结构做出任何假设，使其能够处理今天ASs之间密集的互连网络。BGP版本4的开发是为了处理从有类寻址到无类寻址的变化。在这段时间的大部分时间里，IDRP是并行开发的，这两个协议都是在Merit gatedaemon路由协议套件中实现的。在此期间，IETF内部发生了一场运动，将BGP视为权宜之计，直到更复杂的IDRP能够适应IP而不是OSI无连接协议无连接网络协议（CLNP）的运行。然而，与域内对应的IS-IS不同的是，IDRP最终没有被市场采用。IS-IS经受住了时间的考验，事实证明它比OSPF更灵活。到1995年NSFNET主干网退役时，BGP-4已成为首选的域间路由协议，OSI的明星已经开始衰落。IDRP现在很少被人记住。
A more complete account of the capabilities of IDRP can be found in Chapter 14 of David Piscitello and Lyman Chapin's book "Open Systems Networking: TCP/IP and OSI", which is now readable on the Internet [Chapin94].
有关IDRP功能的更完整说明，请参见David Piscitello和Lyman Chapin的《开放系统网络：TCP/IP和OSI》一书的第14章，该书现在可以在互联网上阅读[Chapin94]。
IDRP also contained quite extensive means for securing routing exchanges, much of it based on X.509 certificates for each router and public-/private-key encryption of routing updates.
IDRP还包含相当广泛的保护路由交换的方法，其中大部分基于每个路由器的X.509证书和路由更新的公钥/私钥加密。
Some of the capabilities of IDRP that might yet appear in a future version of BGP include the ability to manage routes with explicit QoS classes and the concept of domain confederations (somewhat different from the confederation mechanism in today's BGP) as an extra level in the hierarchy of routing.
IDRP的一些功能可能会出现在未来版本的BGP中，包括使用显式QoS类管理路由的能力，以及作为路由层次结构中的额外级别的域联合的概念（与今天的BGP中的联合机制有所不同）。
Nimrod as expressed by Noel Chiappa in his early document, "A New IP Routing and Addressing Architecture" [Chiappa91] and later in the NIMROD working group documents [RFC1753] and [RFC1992] established a number of requirements that need to be considered by any new routing architecture. The Nimrod requirements took RFC 1126 as a starting point and went further.
正如Noel Chiappa在其早期文件“新的IP路由和寻址体系结构”[Chiappa91]以及后来在Nimrod工作组文件[RFC1753]和[RFC1992]中所表达的那样，Nimrod确定了许多需要由任何新路由体系结构考虑的需求。Nimrod需求以RFC1126为起点，并进一步发展。
The three goals of Nimrod, quoted from [RFC1992], were as follows:
引用自[RFC1992]的Nimrod的三个目标如下：
1. To support a dynamic internetwork of _arbitrary size_ (our emphasis) by providing mechanisms to control the amount of routing information that must be known throughout an internetwork.
1. 通过提供控制整个网络中必须知道的路由信息量的机制来支持“任意大小”的动态网络（我们的重点）。
2. To provide service-specific routing in the presence of multiple constraints imposed by service providers and users.
2. 在存在服务提供商和用户施加的多个约束的情况下提供特定于服务的路由。
3. To admit incremental deployment throughout an internetwork.
3. 允许在整个互联网中进行增量部署。
It is certain that these goals should be considered requirements for any new domain-based routing architecture.
可以肯定的是，这些目标应该被视为任何新的基于域的路由体系结构的需求。
o As discussed in other sections of this document, the rate of growth of the amount of information needed to maintain the routing system is such that the system may not be able to scale up as the Internet expands as foreseen. And yet, as the services and constraints upon those services grow, there is a need for more information to be maintained by the routing system. One of the key terms in the first requirements is "control". While increasing amounts of information need to be known and maintained in the Internet, the amounts and kinds of information that are distributed can be controlled. This goal should be reflected in the requirements for the future domain-based architecture.
o 如本文件其他章节所述，维护路由系统所需信息量的增长速度可能导致系统无法随着互联网的扩展而扩展。然而，随着服务和对这些服务的限制的增长，路由系统需要维护更多的信息。第一个要求中的一个关键术语是“控制”。虽然需要在互联网上了解和维护越来越多的信息，但可以控制分发的信息的数量和种类。这一目标应该反映在未来基于领域的体系结构的需求中。
o If anything, the demand for specific services in the Internet has grown since 1996 when the Nimrod architecture was published. Additionally, the kinds of constraints that service providers need to impose upon their networks and that services need to impose upon the routing have also increased. Any changes made to the network in the last half-decade have not significantly improved this situation.
o 如果说有什么区别的话，那就是自1996年Nimrod体系结构发布以来，互联网对特定服务的需求一直在增长。此外，服务提供商需要对其网络施加的约束以及服务需要对路由施加的约束也有所增加。过去五年中对网络所做的任何改变都没有显著改善这种状况。
o The ability to incrementally deploy any new routing architecture within the Internet is still an absolute necessity. It is impossible to imagine that a new routing architecture could supplant the current architecture on a flag day.
o 在Internet中增量部署任何新路由架构的能力仍然是绝对必要的。很难想象在卖旗日，一种新的路由架构会取代当前的架构。
At one point in time, Nimrod, with its addressing and routing architectures, was seen as a candidate for IPng. History shows that it was not accepted as the IPng, having been ruled out of the selection process by the IESG in 1994 on the grounds that it was "too much of a research effort" [RFC1752], although input for the requirements of IPng was explicitly solicited from Chiappa [RFC1753]. Instead, IPv6 has been put forth as the IPng. Without entering a discussion of the relative merits of IPv6 versus Nimrod, it is
有一段时间，Nimrod及其寻址和路由架构被视为IPng的候选者。历史表明，该项目未被接受为IPng，IESG于1994年将其排除在选择过程之外，理由是该项目“太多的研究工作”[RFC1752]，尽管IPng的要求已明确征求Chiapa[RFC1753]的意见。相反，IPv6被提出作为IPng。在没有讨论IPv6与Nimrod的相对优势的情况下，它是
apparent that IPv6, while it may solve many problems, does not solve the critical routing problems in the Internet today. In fact, in some sense, it exacerbates them by adding a requirement for support of two Internet protocols and their respective addressing methods. In many ways, the addition of IPv6 to the mix of methods in today's Internet only points to the fact that the goals, as set forth by the Nimrod team, remain as necessary goals.
显然，IPv6虽然可以解决许多问题，但并不能解决当今互联网中的关键路由问题。事实上，从某种意义上说，它增加了对支持两种互联网协议及其各自寻址方法的要求，从而加剧了这种情况。在许多方面，在今天的互联网上，将IPv6添加到各种方法中，只表明了一个事实，即Nimrod团队提出的目标仍然是必要的目标。
There is another sense in which the study of Nimrod and its architecture may be important to deriving a future domain-based routing architecture. Nimrod can be said to have two derivatives:
在另一种意义上，对Nimrod及其体系结构的研究可能对推导未来基于域的路由体系结构很重要。尼姆罗德可以说有两个衍生物：
o Multi-Protocol Label Switching (MPLS), in that it took the notion of forwarding along well-known paths.
o 多协议标签交换（MPLS），因为它采用沿已知路径转发的概念。
o Private Network-Node Interface (PNNI), in that it took the notion of abstracting topological information and using that information to create connections for traffic.
o 专用网络节点接口（PNNI），因为它采用了抽象拓扑信息的概念，并使用该信息创建流量连接。
It is important to note, that whilst MPLS and PNNI borrowed ideas from Nimrod, neither of them can be said to be an implementation of this architecture.
需要注意的是，尽管MPLS和PNNI借鉴了Nimrod的思想，但它们都不能说是该体系结构的实现。
The Private Network-Node Interface (PNNI) routing protocol was developed under the ATM Forum's auspices as a hierarchical route determination protocol for ATM, a connection-oriented architecture. It is reputed to have developed several of its methods from a study of the Nimrod architecture. What can be gained from an analysis of what did and did not succeed in PNNI?
专用网络节点接口（PNNI）路由协议是在ATM论坛的支持下开发的，作为ATM的分层路由确定协议，一种面向连接的体系结构。据说，它通过对Nimrod体系结构的研究开发了几种方法。从对PNNI成功与否的分析中可以得到什么？
The PNNI protocol includes the assumption that all peer groups are willing to cooperate, and that the entire network is under the same top administration. Are there limitations that stem from this "world node" presupposition? As discussed in [RFC3221], the Internet is no longer a clean hierarchy, and there is a lot of resistance to having any sort of "ultimate authority" controlling or even brokering communication.
PNNI协议假设所有对等组都愿意合作，并且整个网络处于同一高层管理之下。这个“世界节点”预设是否存在局限性？正如[RFC3221]中所讨论的，互联网不再是一个干净的层次结构，人们对任何形式的“最终权威”控制甚至代理通信都有很大的抵制。
PNNI is the first deployed example of a routing protocol that uses abstract map exchange (as opposed to distance-vector or link-state mechanisms) for inter-domain routing information exchange. One consequence of this is that domains need not all use the same mechanism for map creation. What were the results of this abstraction and source-based route calculation mechanism?
PNNI是使用抽象映射交换（与距离向量或链路状态机制相反）进行域间路由信息交换的路由协议的第一个部署示例。这样做的一个结果是，域不必都使用相同的机制来创建映射。这种抽象和基于源代码的路由计算机制的结果是什么？
Since the authors of this document do not have experience running a PNNI network, the comments above are from a theoretical perspective. Further research on these issues based on operational experience is required.
由于本文件的作者没有运行PNNI网络的经验，以上评论是从理论角度进行的。需要根据运行经验对这些问题进行进一步研究。
The work commissioned from Geoff Huston by the Internet Architecture Board [RFC3221] draws a number of conclusions from the analysis of BGP routing tables and routing registry databases:
互联网架构委员会[RFC3221]委托Geoff Huston开展的工作从BGP路由表和路由注册数据库的分析中得出了许多结论：
o The connectivity between provider ASs is becoming more like a dense mesh than the tree structure that was commonly assumed to be commonplace a couple of years ago. This has been driven by the increasing amounts charged for peering and transit traffic by global service providers. Local direct peering and Internet exchanges are becoming steadily more common as the cost of local fibre connections drops.
o 提供商ASs之间的连接越来越像一个密集的网格，而不是几年前通常认为很常见的树结构。这是由于全球服务提供商对对等和传输流量收取的费用不断增加。随着本地光纤连接成本的下降，本地直接对等和Internet交换正变得越来越普遍。
o End-user sites are increasingly resorting to multi-homing onto two or more service providers as a way of improving resiliency. This has a knock-on effect of spectacularly fast depletion of the available pool of AS numbers as end-user sites require public AS numbers to become multi-homed and corresponding increase in the number of prefixes advertised in BGP.
o 最终用户站点越来越多地求助于两个或多个服务提供商的多主服务，以提高恢复能力。这有一个连锁效应，即可用AS号码池的惊人快速消耗，因为最终用户站点要求公共AS号码成为多址，并且BGP中广告的前缀数量相应增加。
o Multi-homed sites are using advertisement of longer prefixes in BGP as a means of traffic engineering to load spread across their multiple external connections with further impact on the size of the BGP tables.
o 多宿主站点正在使用BGP中较长前缀的广告作为流量工程的一种手段，以跨其多个外部连接进行负载分配，从而进一步影响BGP表的大小。
o Operational practices are not uniform, and in some cases lack of knowledge or training is leading to instability and/or excessive advertisement of routes by incorrectly configured BGP speakers.
o 运营实践并不统一，在某些情况下，缺乏知识或培训会导致不稳定和/或错误配置的BGP扬声器过度宣传路线。
o All these factors are quickly negating the advantages in limiting the expansion of BGP routing tables that were gained by the introduction of Classless Inter-Domain Routing (CIDR) and consequent prefix aggregation in BGP. It is also now impossible for IPv6 to realize the worldview in which the default-free zone would be limited to perhaps 10,000 prefixes.
o 所有这些因素都很快否定了通过在BGP中引入无类域间路由（CIDR）和随后的前缀聚合而获得的限制BGP路由表扩展的优势。IPv6现在也不可能实现默认自由区限制在10000个前缀以内的世界观。
o The typical "width" of the Internet in AS hops is now around five, and much less in many cases.
o 在AS-hops中，互联网的典型“宽度”现在约为5，在许多情况下要小得多。
These conclusions have a considerable impact on the requirements for the future domain-based routing architecture:
这些结论对未来基于域的路由体系结构的需求有很大影响：
o Topological hierarchy (e.g., mandating a tree-structured connectivity) cannot be relied upon to deliver scalability of a large Internet routing system.
o 拓扑层次结构（例如，强制树结构连接）不能用来提供大型Internet路由系统的可伸缩性。
o Aggregation cannot be relied upon to constrain the size of routing tables for an all-informed routing system.
o 对于全信息路由系统，不能依靠聚合来限制路由表的大小。
DARPA funded a project to think about a new architecture for future generation Internet, called NewArch (see http://www.isi.edu/newarch/). Work started in the first half of 2000 and the main project finished in 2003 [NewArch03].
DARPA资助了一个项目，为下一代互联网设计一种新的架构，称为NewArch（参见http://www.isi.edu/newarch/). 工作于2000年上半年开始，主要项目于2003年完成[NewArch03]。
The main development is to conclude that as the Internet becomes mainstream infrastructure, fewer and fewer of the requirements are truly global but may apply with different force or not at all in certain parts of the network. This (it is claimed) makes the compilation of a single, ordered list of requirements deeply problematic. Instead, we may have to produce multiple requirement sets with support for differing requirement importance at different times and in different places. This "meta-requirement" significantly impacts architectural design.
主要的发展是得出结论，随着互联网成为主流基础设施，真正全球化的需求越来越少，但可能以不同的力量应用于网络的某些部分，或者根本不应用于网络的某些部分。这（据称）使得编写一个单一的、有序的需求列表变得非常困难。相反，我们可能需要生成多个需求集，并在不同的时间和地点支持不同的需求重要性。这种“元需求”对架构设计产生了重大影响。
Potential new technical requirements identified so far include:
目前确定的潜在新技术要求包括：
o Commercial environment concerns such as richer inter-provider policy controls and support for a variety of payment models
o 商业环境问题，如更丰富的供应商间政策控制和对各种支付模式的支持
o Trustworthiness
o 诚信
o Ubiquitous mobility
o 无处不在的移动性
o Policy driven self-organization ("deep auto-configuration")
o 策略驱动的自组织（“深度自动配置”）
o Extreme short-timescale resource variability
o 极短时间尺度资源可变性
o Capacity allocation mechanisms
o 能力分配机制
o Speed, propagation delay, and delay/bandwidth product issues
o 速度、传播延迟和延迟/带宽乘积问题
Non-technical or political "requirements" include:
非技术性或政治性“要求”包括：
o Legal and Policy drivers such as
o 法律和政策驱动因素，如
* Privacy and free/anonymous speech
* 隐私和自由/匿名言论
* Intellectual property concerns
* 知识产权问题
* Encryption export controls
* 加密出口管制
* Law enforcement surveillance regulations
* 执法监察规例
* Charging and taxation issues
* 收费及税务事宜
o Reconciling national variations and consistent operation in a worldwide infrastructure
o 在全球基础设施中协调国家差异和一致运行
The conclusions of the work are now summarized in the final report [NewArch03].
最终报告[NewArch03]总结了工作结论。
One of the participants in DARPA NewArch work (Dave Clark) with one of his associates has also published a very interesting paper analyzing the impact of some of the new requirements identified in NewArch (see Section 4.2) on the end-to-end principle that has guided the development of the Internet to date [Clark00]. Their primary conclusion is that the loss of trust between the users at the ends of end-to-end has the most fundamental effect on the Internet. This is clear in the context of the routing system, where operators are unwilling to reveal the inner workings of their networks for commercial reasons. Similarly, trusted third parties and their avatars (mainly midboxes of one sort or another) have a major impact on the end-to-end principles and the routing mechanisms that went with them. Overall, the end-to-end principles should be defended so far as is possible -- some changes are already too deeply embedded to make it possible to go back to full trust and openness -- at least partly as a means of staving off the day when the network will ossify into an unchangeable form and function (much as the telephone network has done). The hope is that by that time, a new Internet will appear to offer a context for unfettered innovation.
DARPA NewArch工作的一名参与者（Dave Clark）及其一名同事也发表了一篇非常有趣的论文，分析了NewArch中确定的一些新要求（见第4.2节）对迄今为止指导互联网发展的端到端原则的影响[Clark00]。他们的主要结论是，端到端用户之间的信任缺失对互联网产生了最根本的影响。这一点在路由系统中是显而易见的，因为运营商出于商业原因不愿透露其网络的内部工作。类似地，受信任的第三方及其化身（主要是一种或另一种中间盒）对端到端原则和随之产生的路由机制具有重大影响。总的来说，端到端的原则应该尽可能地得到捍卫——一些变化已经根深蒂固，不可能回到完全信任和开放的状态——至少部分是为了避免网络僵化为不可改变的形式和功能（就像电话网所做的那样）的那一天。希望到那时，一个新的互联网将为不受约束的创新提供环境。
5. Existing Problems of BGP and the Current Inter-/Intra-Domain Architecture
5. BGP存在的问题和当前的域间/域内体系结构
Although most of the people who have to work with BGP today believe it to be a useful, working protocol, discussions have brought to light a number of areas where BGP or the relationship between BGP and the intra-domain routing protocols in use today could be improved. BGP-4 has been and continues to be extended since it was originally introduced in [RFC1771] and the protocol as deployed has been documented in [RFC4271]. This section is, to a large extent, a wish
尽管今天必须使用BGP的大多数人认为它是一种有用的工作协议，但讨论揭示了BGP或BGP与当前使用的域内路由协议之间的关系可以改进的一些领域。自[RFC1771]最初引入BGP-4以来，BGP-4已经并将继续扩展，并且部署的协议已记录在[RFC4271]中。这一部分在很大程度上是一个愿望
list for the future domain-based routing architecture based on those areas where BGP is seen to be lacking, rather than simply a list of problems with BGP. The shortcomings of today's inter-domain routing system have also been extensively surveyed in "Architectural Requirements for Inter-Domain Routing in the Internet" [RFC3221], particularly with respect to its stability and the problems produced by explosions in the size of the Internet.
未来基于域的路由体系结构列表，基于那些被认为缺乏BGP的领域，而不仅仅是BGP问题列表。“Internet域间路由的体系结构要求”[RFC3221]中也对当今域间路由系统的缺点进行了广泛的调查，特别是关于其稳定性和Internet规模爆炸所产生的问题。
The initial stability followed by linear growth rates of the number of routing objects (prefixes) that was achieved by the introduction of CIDR around 1994, has now been once again been replaced by near-exponential growth of number of routing objects. The granularity of many of the objects advertised in the default-free zone is very small (prefix length of 22 or longer): this granularity appears to be a by-product of attempts to perform precision traffic engineering related to increasing levels of multi-homing. At present, there is no mechanism in BGP that would allow an AS to aggregate such prefixes without advance knowledge of their existence, even if it was possible to deduce automatically that they could be aggregated. Achieving satisfactory auto-aggregation would also significantly reduce the non-locality problems associated with instability in peripheral ASs.
1994年左右引入CIDR后，路由对象（前缀）数量的初始稳定性和线性增长率再次被路由对象数量的指数级增长所取代。在默认自由区中公布的许多对象的粒度非常小（前缀长度为22或更长）：此粒度似乎是尝试执行与不断增加的多归属级别相关的精确流量工程的副产品。目前，BGP中没有允许AS在事先不知道前缀存在的情况下聚合此类前缀的机制，即使可以自动推断它们可以聚合。实现令人满意的自动聚合还将显著减少与外围ASs中的不稳定性相关的非局部性问题。
On the other hand, it may be that alterations to the connectivity of the net as described in [RFC3221] and Section 2.5.1 may limit the usefulness of auto-aggregation.
另一方面，[RFC3221]和第2.5.1节中所述的网络连接变更可能会限制自动聚合的用途。
BGP today is a stable protocol under most circumstances, but this has been achieved at the expense of making the convergence time of the inter-domain routing system very slow under some conditions. This has a detrimental effect on the recovery of the network from failures.
如今，BGP在大多数情况下都是稳定的协议，但在某些情况下，这是以牺牲域间路由系统的收敛时间为代价的。这对从故障中恢复网络有不利影响。
The timers that control the behavior of BGP are typically set to values in the region of several tens of seconds to a few minutes, which constrains the responsiveness of BGP to failure conditions.
控制BGP行为的计时器通常设置为几十秒到几分钟的值，这限制了BGP对故障条件的响应。
In the early days of deployment of BGP, poor network stability and router software problems lead to storms of withdrawals closely followed by re-advertisements of many prefixes. To control the load on routing software imposed by these "route flaps", route-flap damping was introduced into BGP. Most operators have now implemented a degree of route-flap damping in their deployments of BGP. This restricts the number of times that the routing tables will be rebuilt, even if a route is going up and down very frequently.
在部署BGP的早期，网络稳定性差和路由器软件问题导致大量的退出，紧接着是许多前缀的重新发布。为了控制这些“路由襟翼”施加在路由软件上的负载，在BGP中引入路由襟翼阻尼。大多数运营商现在在部署BGP时都实施了一定程度的路由衰减。这限制了重建路由表的次数，即使路由非常频繁地上下移动。
Unfortunately, route-flap damping responds to multiple flaps by increasing the route suppression time exponentially, which can result in some parts of the Internet being unreachable for hours at a time.
不幸的是，路由襟翼阻尼通过成倍增加路由抑制时间来响应多个襟翼，这可能会导致互联网的某些部分在数小时内无法访问。
There is evidence ([RFC3221] and measurements by some of the Sub-Group B members [Jiang02]) that in today's network, route flap is disproportionately associated with the fine-grained prefixes (length 22 or longer) associated with traffic engineering at the periphery of the network. Auto-aggregation, as previously discussed, would tend to mask such instability and prevent it being propagated across the whole network. Another question that needs to be studied is the continuing need for an architecture that requires global convergence. Some of our studies (unpublished) show that, in some localities at least, the network never actually reaches stability; i.e., it never really globally converges. Can a global, and beyond, network be designed with the requirement of global convergence?
有证据（[RFC3221]和一些B组成员[Jiang02]的测量结果表明，在今天的网络中，路由瓣与网络外围与流量工程相关的细粒度前缀（长度22或更长）不成比例地关联。如前所述，自动聚合往往会掩盖这种不稳定性，并防止其在整个网络中传播。另一个需要研究的问题是对需要全局收敛的体系结构的持续需求。我们的一些研究（未发表）表明，至少在一些地方，网络从未真正达到稳定；i、 例如，它从未真正实现全球收敛。一个全球性的、超越性的网络能否按照全球融合的要求进行设计？
There have been a number of instances, some of which are well documented, of a mistake in BGP configuration in a single peripheral AS propagating across the whole Internet and resulting in misrouting of most of the traffic in the Internet.
有许多实例（其中一些已被充分记录）表明，单个外围设备中的BGP配置错误会在整个互联网上传播，并导致互联网中大部分流量的错误路由。
Similarly, a single route flap in a single peripheral AS can require route table recalculation across the entire Internet.
类似地，单个外围设备中的单个路由活门可能需要在整个Internet上重新计算路由表。
This non-locality of effects is highly undesirable, and it would be a considerable improvement if such effects were naturally limited to a small area of the network around the problem. This is another argument for an architecture that does not require global convergence.
这种影响的非局部性是非常不可取的，如果这种影响自然地局限于问题周围网络的一小部分，这将是一个相当大的改进。这是不需要全局收敛的体系结构的另一个论点。
As discussed previously, the increasing use of multi-homing as a robustness technique by peripheral networks requires that multiple routes have to be advertised for such domains. These routes must not be aggregated close in to the multi-homed domain as this would defeat the traffic engineering implied by multi-homing and currently cannot be aggregated further away from the multi-homed domain due to the lack of auto-aggregation capabilities. Consequentially, the default-free zone routing table is growing exponentially, as it was before CIDR.
如前所述，外围网络越来越多地使用多归属作为一种健壮性技术，这要求必须为此类域宣传多条路由。这些路由不能聚集在多宿主域附近，因为这将破坏多宿主所隐含的流量工程，并且由于缺乏自动聚集功能，目前无法聚集在远离多宿主域的地方。因此，与CIDR之前一样，默认的自由区路由表呈指数增长。
The longest prefix match routing technique introduced by CIDR, and implemented in BGP-4, when combined with provider address allocation is an obstacle to effective multi-homing if load sharing across the
CIDR引入并在BGP-4中实现的最长前缀匹配路由技术与提供商地址分配相结合，如果跨网络负载共享，则会阻碍有效的多主路由
multiple links is required. If an AS has been allocated, its addresses from an upstream provider, the upstream provider can aggregate those addresses with those of other customers and need only advertise a single prefix for a range of customers. But, if the customer AS is also connected to another provider, the second provider is not able to aggregate the customer addresses because they are not taken from his allocation, and will therefore have to announce a more specific route to the customer AS. The longest match rule will then direct all traffic through the second provider, which is not as required.
需要多个链接。如果AS已从上游提供商处分配其地址，则上游提供商可以将这些地址与其他客户的地址聚合，并且只需要为一系列客户发布一个前缀。但是，如果客户AS还连接到另一个提供商，则第二个提供商无法聚合客户地址，因为这些地址不是从其分配中获取的，因此必须向客户AS宣布更具体的路由。然后，最长匹配规则将引导所有流量通过第二个提供程序，这不是必需的。
Example:
例子：
\ /
AS1 AS2
\ /
AS3
\ /
AS1 AS2
\ /
AS3
Figure 1: Address Aggregation
图1：地址聚合
In Figure 1, AS3 has received its addresses from AS1, which means AS1 can aggregate. But if AS3 wants its traffic to be seen equally both ways, AS3 is forced to announce both the aggregate and the more specific route to AS2.
在图1中，AS3已从AS1接收到其地址，这意味着AS1可以聚合。但是，如果AS3希望它的流量在两个方面都能被平等地看待，那么AS3将被迫宣布通往AS2的总路线和更具体的路线。
This problem has induced many ASs to apply for their own address allocation even though they could have been allocated from an upstream provider further exacerbating the default-free zone route table size explosion. This problem also interferes with the desire of many providers in the default-free zone to route only prefixes that are equal to or shorter than 20 or 19 bits.
这个问题导致许多ASs申请自己的地址分配，即使它们可能是从上游提供商处分配的，这进一步加剧了默认自由区路由表大小的爆炸。这个问题还干扰了默认自由区中许多提供者只路由等于或小于20或19位的前缀的愿望。
Note that some problems that are referred to as multi-homing issues are not, and should not be, solvable through the routing system (e.g., where a TCP load distributor is needed), and multi-homing is not a panacea for the general problem of robustness in a routing system [Berkowitz01].
请注意，一些被称为多宿主问题的问题不是也不应该通过路由系统来解决的（例如，在需要TCP负载分配器的情况下），多宿主并不是解决路由系统健壮性一般问题的灵丹妙药[Berkowitz 01]。
Editors' Note: A more recent analysis of multi-homing can be found in [RFC4116].
编者注：关于多归宿的最新分析可以在[RFC4116]中找到。
The domain identifier or AS number is a 16-bit number. When this paper was originally written in 2001, allocation of AS numbers was increasing 51% a year [RFC3221] and exhaustion by 2005 was predicted.
域标识符或AS编号为16位数字。当本文最初于2001年撰写时，AS数量的分配每年增加51%[RFC3221]，预计到2005年将耗尽。
According to some recent work again by Huston [Huston05], the rate of increase dropped off after the business downturn, but as of July 2005, well over half the available AS numbers (39000 out of 64510) had been allocated by IANA and around 20000 were visible in the global BGP routing tables. A year later, these figures had grown to 42000 (April 2006) and 23000 (August 2006), respectively, and the rate of allocation is currently about 3500 per year. Depending on the curve-fitting model used to predict when exhaustion will occur, the pool will run out somewhere between 2010 and 2013. There appear to be other factors at work in this rate of increase beyond an increase in the number of ISPs in business, although there is a fair degree of correlation between these numbers. AS numbers are now used for a number of purposes beyond that of identifying large routing domains: multi-homed sites acquire an AS number in order to express routing preferences to their various providers and AS numbers are used part of the addressing mechanism for MPLS/BGP-based virtual private networks (VPNs) [RFC4364]. The IETF has had a proposal under development for over four years to increase the available range of AS numbers to 32 bits [RFC4893]. Much of the slowness in development is due to the deployment challenge during transition. Because of the difficulties of transition, deployment needs to start well in advance of actual exhaustion so that the network as a whole is ready for the new capability when it is needed. This implies that standardization needs to be complete and implementations available at least well in advance of expected exhaustion so that deployment of upgrades that can handle the longer AS numbers, should be starting around 2008, to give a reasonable expectation that the change has been rolled out across a large fraction of the Internet by the time exhaustion occurs.
根据Huston[Huston05]最近的一些研究，增长率在业务下滑后有所下降，但截至2005年7月，超过一半的可用as号码（64510中的39000个）是由IANA分配的，在全球BGP路由表中可以看到约20000个。一年后，这些数字分别增长到42000（2006年4月）和23000（2006年8月），目前每年的分配率约为3500。根据用于预测何时会出现枯竭的曲线拟合模型，该池将在2010年至2013年间耗尽。在这一增长率中，除了运营中的ISP数量增加之外，似乎还有其他因素在起作用，尽管这些数字之间存在一定程度的相关性。AS编号现在用于识别大型路由域之外的许多目的：多宿站点获取AS编号，以便向其各种提供商表示路由偏好，AS编号是基于MPLS/BGP的虚拟专用网络（VPN）寻址机制的一部分[RFC4364]。IETF已经有一项提案在开发中超过四年，该提案将AS编号的可用范围增加到32位[RFC4893]。开发的缓慢在很大程度上是由于过渡期间的部署挑战。由于过渡的困难，部署需要在实际耗尽之前尽早开始，以便整个网络在需要时为新能力做好准备。这意味着标准化需要完成，并且至少在预期耗尽之前很早就可以实现，以便能够处理更长时间的升级部署应该在2008年左右开始，给出一个合理的预期，即当耗尽发生时，这种变化已经在互联网的很大一部分上展开。
Editors' Note: The Regional Internet Registries (RIRs) are planning to move to assignment of the longer AS numbers by default on 1 January 2009, but there are concerns that significant numbers of routers will not have been upgraded by then.
编者按：区域互联网注册处（RIR）计划在2009年1月1日开始默认分配较长的AS号码，但有人担心届时大量路由器将无法升级。
Tricks with discontinuous ASs are used by operators, for example, to implement anycast. Discontinuous ASs may also come into being by chance if a multi-homed domain becomes partitioned as a result of a fault and part of the domain can access the Internet through each connection. It may be desirable to make support for this kind of situation more transparent than it is at present.
例如，操作符使用带有不连续ASs的技巧来实现选播。如果多宿域由于故障而被分区，并且部分域可以通过每个连接访问Internet，那么不连续的ASs也可能是偶然形成的。可能需要使对这种情况的支持比目前更加透明。
Load splitting or sharing was not a goal of the original designers of BGP and it is now a problem for today's network designers and managers. Trying to fool BGP into load sharing between several links is a constantly recurring exercise for most operators today.
负载拆分或共享不是BGP最初设计者的目标，现在它已成为当今网络设计者和管理者的问题。对于今天的大多数运营商来说，试图愚弄BGP在多个链路之间共享负载是一个经常重复的练习。
As with the interval between "hello" messages in OSPF, the typical size and defined granularity (seconds to tens of seconds) of the "keepalive" time negotiated at start-up for each BGP connection constrains the responsiveness of BGP to link failures.
与OSPF中“hello”消息之间的间隔一样，启动时为每个BGP连接协商的“keepalive”时间的典型大小和定义的粒度（秒到几十秒）限制了BGP对链路故障的响应。
The recommended values and the available lower limit for this timer were set to limit the overhead caused by keepalive messages when link bandwidths were typically much lower than today. Analysis and experiment ([Alaettinoglu00], [Sandiick00] and [RFC4204]) indicate that faster links could sustain a much higher rate of keepalive messages without significantly impacting normal data traffic. This would improve responsiveness to link and node failures but with a corresponding increase in the risk of instability, if the error characteristics of the link are not taken properly into account when setting the keepalive interval.
此计时器的建议值和可用下限被设置为在链路带宽通常比今天低很多的情况下限制keepalive消息造成的开销。分析和实验（[Alaettinoglu00]、[Sandiick00]和[RFC4204]）表明，更快的链路可以在不显著影响正常数据流量的情况下维持更高的保留消息速率。这将提高对链路和节点故障的响应能力，但如果在设置keepalive interval时未正确考虑链路的错误特征，则不稳定风险相应增加。
Editors' Note: A "fast" liveness protocol has been specified in [Katz10].
编者注：在[Katz10]中指定了“快速”活性协议。
An additional problem with the hold-down mechanism in BGP is the amount of information that has to be exchanged to re-establish the database of route advertisements on each side of the link when it is re-established after a failure. Currently any failure, however brief forces a full exchange that could perhaps be constrained by retaining some state across limited time failures and using revision control, transaction and replication techniques to resynchronize the databases. Various techniques have been implemented to try to reduce this problem, but they have not yet been standardized.
BGP中的抑制机制的另一个问题是，在故障后重新建立链路每侧的路由广告数据库时，必须交换的信息量。目前，任何故障（无论多么短暂）都会强制进行完整的交换，这可能会受到限制，因为在有限的故障时间内保留某些状态，并使用修订控制、事务和复制技术来重新同步数据库。为了减少这个问题，已经实施了各种技术，但它们尚未标准化。
Today, many operators' backbone routers run both I-BGP and an intra-domain protocol to maintain the routes that reach between the borders of the domain. Exporting routes from BGP into the intra-domain protocol in use and bringing them back up to BGP is not recommended [RFC2791], but it is still necessary for all backbone routers to run both protocols. BGP is used to find the egress point and intra-
如今，许多运营商的主干路由器同时运行I-BGP和域内协议，以维护到达域边界之间的路由。不建议将路由从BGP导出到正在使用的域内协议中并将其恢复到BGP[RFC2791]，但所有主干路由器仍有必要运行这两个协议。BGP用于查找出口点和内部通道-
domain protocol to find the path (next-hop router) to the egress point across the domain. This is not only a management problem but may also create other problems:
域协议，用于查找跨域出口点的路径（下一跳路由器）。这不仅是一个管理问题，还可能造成其他问题：
o BGP is a path-vector protocol (i.e., a protocol that uses distance metrics possibly overridden by policy metrics), whereas most intra-domain protocols are link-state protocols. As such, BGP is not optimized for convergence speed although distance-vector algorithms generally require less processing power. Incidentally, more efficient distance-vector algorithms are available such as [Xu97].
o BGP是一种路径向量协议（即，使用可能被策略度量覆盖的距离度量的协议），而大多数域内协议是链路状态协议。因此，虽然距离向量算法通常需要较少的处理能力，但BGP并没有针对收敛速度进行优化。顺便提一下，可以使用更有效的距离向量算法，如[Xu97]。
o The metrics used in BGP and the intra-domain protocol are rarely comparable or combinable. Whilst there are arguments that the optimizations inside a domain may be different from those for end-to-end paths, there are occasions, such as calculating the "topologically nearest" server when computable or combinable metrics would be of assistance.
o BGP和域内协议中使用的度量很少具有可比性或可组合性。虽然有人认为域内的优化可能不同于端到端路径的优化，但也有一些情况，例如计算“拓扑上最近的”服务器时，可计算或可组合的度量将有所帮助。
o The policies that can be implemented using BGP are designed for control of traffic exchange between operators, not for controlling paths within a domain. Policies for BGP are most conveniently expressed in Routing Policy Support Language (RPSL) [RFC2622] and this could be extended if thought desirable to include additional policy information.
o 可以使用BGP实现的策略旨在控制运营商之间的流量交换，而不是控制域内的路径。BGP的策略最方便地用路由策略支持语言（RPSL）[RFC2622]表示，如果认为需要包括额外的策略信息，可以对其进行扩展。
o If the NEXT HOP destination for a set of BGP routes becomes inaccessible because of intra-domain protocol problems, the routes using the vanished next hop have to be invalidated at the next available UPDATE. Subsequently, if the next-hop route reappears, this would normally lead to the BGP speaker requesting a full table from its neighbor(s). Current implementations may attempt to circumvent the effects of intra-domain protocol route flap by caching the invalid routes for a period in case the next hop is restored through the "graceful restart" mechanism.
o 如果由于域内协议问题，一组BGP路由的下一跳目标变得不可访问，则使用消失的下一跳的路由必须在下一次可用更新时失效。随后，如果下一跳路由重新出现，这通常会导致BGP扬声器向其邻居请求一个完整的表。当前的实现可能试图通过将无效路由缓存一段时间来避免域内协议路由抖动的影响，以防下一跳通过“优雅重启”机制恢复。
Editors' Note: This was standardized as [RFC4724].
编者注：这被标准化为[RFC4724]。
o Synchronization between intra-domain and inter-domain routing information is a problem as long as we use different protocols for intra-domain and inter-domain routing, which will most probably be the case even in the future because of the differing requirements in the two situations. Some sort of synchronization between those two protocols would be useful. In the RFC "IS-IS Transient Blackhole Avoidance" [RFC3277], the intra-domain protocol side of the story is covered (there is an equivalent discussion for OSPF).
o 只要我们对域内和域间路由使用不同的协议，域内和域间路由信息之间的同步就是一个问题，因为这两种情况下的需求不同，所以即使在将来也很可能会出现这种情况。这两个协议之间的某种同步将是有用的。在RFC“IS-IS瞬态黑洞避免”[RFC3277]中，涵盖了故事的域内协议方面（对OSPF也有类似的讨论）。
o Synchronizing in BGP means waiting for the intra-domain protocol to know about the same networks as the inter-domain protocol, which can take a significant period of time and slows down the convergence of BGP by adding the intra-domain protocol convergence time into each cycle. In general, operators no longer attempt full synchronization in order to avoid this problem (in general, redistributing the entire BGP routing feed into the local intra-domain protocol is unnecessary and undesirable but where a domain has multiple exits to peers and other non-customer networks, changes in BGP routing that affect the exit taken by traffic require corresponding re-routing in the intra-domain routing).
o 在BGP中同步意味着等待域内协议了解与域间协议相同的网络，这可能需要很长的时间，并通过在每个周期中添加域内协议收敛时间来减慢BGP的收敛速度。通常，操作员不再尝试完全同步以避免此问题（一般来说，将整个BGP路由馈送重新分配到本地域内协议是不必要的，也是不可取的，但如果一个域有多个到对等方和其他非客户网络的出口，则影响流量采取的出口的BGP路由的更改需要在域内路由中进行相应的重新路由）。
There are several classes of issues with current BGP policy:
当前BGP政策存在几类问题：
o Policy is installed in an ad hoc manner in each autonomous system. There isn't a method for ensuring that the policy installed in one router is coherent with policies installed in other routers.
o 策略以特别方式安装在每个自治系统中。没有一种方法可以确保安装在一个路由器中的策略与安装在其他路由器中的策略一致。
o As described in Griffin [Griffin99] and in McPherson [RFC3345], it is possible to create policies for ASs, and instantiate them in routers, that will cause BGP to fail to converge in certain types of topology
o 如Griffin[Griffin 99]和McPherson[RFC3345]所述，可以为ASs创建策略，并在路由器中实例化它们，这将导致BGP无法在某些类型的拓扑中收敛
o There is no available network model for describing policy in a coherent manner.
o 没有可用的网络模型以连贯的方式描述策略。
Policy management is extremely complex and mostly done without the aid of any automated procedures. The extreme complexity means that a highly-qualified specialist is required for policy management of border routers. The training of these specialists is quite lengthy and needs to involve long periods of hands-on experience. There is, therefore, a shortage of qualified staff for installing and maintaining the routing policies. Because of the overall complexity of BGP, policy management tends to be only a relatively small topic within a complete BGP training course and specialized policy management training courses are not generally available.
策略管理非常复杂，而且大多数情况下都没有任何自动化过程的帮助。极端的复杂性意味着需要一名高素质的专家来管理边界路由器的策略。这些专家的培训相当长，需要长期的实践经验。因此，缺乏合格的人员来安装和维护路由策略。由于BGP的总体复杂性，在完整的BGP培训课程中，策略管理往往只是一个相对较小的主题，并且一般不提供专门的策略管理培训课程。
While many of the issues with BGP security have been traced either to implementation issues or to operational issues, BGP is vulnerable to Distributed Denial of Service (DDoS) attacks. Additionally, routers can be used as unwitting forwarders in DDoS attacks on other systems.
虽然BGP的许多安全问题都可以追溯到实施问题或操作问题，但BGP容易受到分布式拒绝服务（DDoS）攻击。此外，在对其他系统的DDoS攻击中，路由器可以用作不知情的转发器。
Though DDoS attacks can be fought in a variety of ways, mostly using filtering methods, it takes constant vigilance. There is nothing in the current architecture or in the protocols that serves to protect the forwarders from these attacks.
虽然DDoS攻击可以通过多种方式进行打击，主要是使用过滤方法，但需要时刻保持警惕。当前的体系结构或协议中没有任何内容可以保护转发器免受这些攻击。
Editors' Note: Since the original document was written, the issue of inter-domain routing security has been studied in much greater depth. The rpsec working group has gone into the security issues in great detail [RFC4593] and readers should refer to that work to understand the security issues.
编者按：自原始文档编写以来，域间路由安全问题已经得到了更深入的研究。rpsec工作组已经非常详细地研究了安全问题[RFC4593]，读者应该参考该工作来了解安全问题。
Recently, BGP has been modified to function as a signaling protocol for MPLS and for VPNs [RFC4364]. Some people see this overloading of the BGP protocol as a boon whilst others see it as a problem. While it was certainly convenient as a vehicle for vendors to deliver extra functionality to their products, it has exacerbated some of the performance and complexity issues of BGP. Two important problems are that, the additional state that must be retained and refreshed to support VPN (Virtual Private Network) tunnels and that BGP does not provide end-to-end notification making it difficult to confirm that all necessary state has been installed or updated.
最近，BGP被修改为MPLS和VPN的信令协议[RFC4364]。一些人认为BGP协议的过载是一个福音，而另一些人认为这是一个问题。虽然作为供应商向其产品提供额外功能的工具，它当然很方便，但它加剧了BGP的一些性能和复杂性问题。两个重要问题是，必须保留和刷新的附加状态以支持VPN（虚拟专用网络）隧道，以及BGP不提供端到端通知，这使得很难确认所有必要的状态都已安装或更新。
It is an open question whether VPN signaling protocols should remain separate from the route determination protocols.
VPN信令协议是否应与路由确定协议保持分离是一个悬而未决的问题。
The fact that service providers need to maintain two completely separate networks, one for IPv4 and one for IPv6, has been a real hindrance to the introduction of IPv6. When IPv6 does get widely deployed, it will do so without causing the disappearance of IPv4. This means that unless something is done, service providers would need to maintain the two networks in perpetuity (at least on the foreshortened timescale which the Internet world uses).
事实上，服务提供商需要维护两个完全独立的网络，一个用于IPv4，另一个用于IPv6，这是IPv6引入的真正障碍。当IPv6得到广泛部署时，它将在不导致IPv4消失的情况下实现这一点。这意味着，除非采取行动，否则服务提供商将需要永久维护这两个网络（至少在互联网世界使用的缩短时间尺度上）。
It is possible to use a single set of BGP speakers with multi-protocol extensions [RFC4760] to exchange information about both IPv4 and IPv6 routes between domains, but the use of TCP as the transport protocol for the information exchange results in an asymmetry when choosing to use one of TCP over IPv4 or TCP over IPv6. Successful information exchange confirms one of IPv4 or IPv6 reachability between the speakers but not the other, making it possible that reachability is being advertised for a protocol for which it is not present.
可以使用一组具有多协议扩展[RFC4760]的BGP扬声器在域之间交换有关IPv4和IPv6路由的信息，但使用TCP作为信息交换的传输协议会导致在选择使用TCP over IPv4或TCP over IPv6时出现不对称。成功的信息交换确认了说话者之间的IPv4或IPv6可达性之一，而不是另一个，这使得可能正在为不存在可达性的协议播发可达性。
Also, current implementations do not allow a route to be advertised for both IPv4 and IPv6 in the same UPDATE message, because it is not possible to explicitly link the reachability information for an address family to the corresponding next-hop information. This could be improved, but currently results in independent UPDATEs being exchanged for each address family.
此外，当前的实现不允许在同一更新消息中为IPv4和IPv6播发路由，因为不可能将地址族的可达性信息显式链接到相应的下一跳信息。这是可以改进的，但目前每个地址族都会交换独立的更新。
5.14. Existing Tools to Support Effective Deployment of Inter-Domain Routing
5.14. 支持有效部署域间路由的现有工具
The tools available to network operators to assist in configuring and maintaining effective inter-domain routing in line with their defined policies are limited, and almost entirely passive.
网络运营商根据其定义的策略来帮助配置和维护有效的域间路由的工具是有限的，而且几乎完全是被动的。
o There are no tools to facilitate the planning of the routing of a domain (either intra- or inter-domain); there are a limited number of display tools that will visualize the routing once it has been configured.
o 没有工具来促进域（域内或域间）路由的规划；配置布线后，将可视化布线的显示工具数量有限。
o There are no tools to assist in converting business policy specifications into the Routing Policy Specification Language (RPSL) language (see Section 5.14.1); there are limited tools to convert the RPSL into BGP commands and to check, post-facto, that the proposed policies are consistent with the policies in adjacent domains (always provided that these have been revealed and accurately documented).
o 没有工具帮助将业务策略规范转换为路由策略规范语言（RPSL）（见第5.14.1节）；将RPSL转换为BGP命令以及事后检查建议的策略是否与相邻域中的策略一致（前提是这些策略已被披露并准确记录）的工具有限。
o There are no tools to monitor BGP route changes in real-time and warn the operator about policy inconsistencies and/or instabilities.
o 没有工具实时监控BGP路由变化，并就策略不一致和/或不稳定向运营商发出警告。
The following section summarizes the tools that are available to assist with the use of RPSL. Note they are all batch mode tools used off-line from a real network. These tools will provide checks for skilled inter-domain routing configurers but limited assistance for the novice.
下一节总结了可用于帮助使用RPSL的工具。注意，它们都是从实际网络离线使用的批处理模式工具。这些工具将为熟练的域间路由配置人员提供检查，但对新手的帮助有限。
5.14.1. Routing Policy Specification Language RPSL (RFC 2622 and RFC 2650) and RIPE NCC Database (RIPE 157)
5.14.1. 路由策略规范语言RPSL（RFC 2622和RFC 2650）和成熟的NCC数据库（成熟的157）
Routing Policy Specification Language (RPSL) [RFC2622] enables a network operator to describe routes, routers, and Autonomous Systems (ASs) that are connected to the local AS.
路由策略规范语言（RPSL）[RFC2622]使网络运营商能够描述连接到本地AS的路由、路由器和自治系统（ASs）。
Using the RPSL language (see [RFC2650]) a distributed database is created to describe routing policies in the Internet as described by each AS independently. The database can be used to check the consistency of routing policies stored in the database.
使用RPSL语言（参见[RFC2650]）创建了一个分布式数据库，用于描述互联网中的路由策略，每个数据库都独立地进行了描述。数据库可用于检查存储在数据库中的路由策略的一致性。
Tools exist [IRRToolSet] that can use the database to (among other things):
现有的[IRRToolSet]工具可以使用数据库来（除其他外）：
o Flag when two neighboring network operators specify conflicting or inconsistent routing information exchanges with each other and also detect global inconsistencies where possible;
o 当两个相邻网络运营商指定相互冲突或不一致的路由信息交换时进行标记，并在可能的情况下检测全局不一致；
o Extract all AS-paths between two networks that are allowed by routing policy from the routing policy database; display the connectivity a given network has according to current policies.
o 从路由策略数据库中提取路由策略允许的两个网络之间的所有AS路径；根据当前策略显示给定网络的连接。
The database queries enable a partial-static solution to the convergence problem. They analyze routing policies of a very limited part of Internet and verify that they do not contain conflicts that could lead to protocol divergence. The static analysis of convergence of the entire system has exponential time complexity, so approximation algorithms would have to be used.
数据库查询可以部分静态地解决收敛问题。他们分析了互联网非常有限部分的路由策略，并验证它们不包含可能导致协议分歧的冲突。整个系统收敛性的静态分析具有指数时间复杂性，因此必须使用近似算法。
The toolset also allows router configurations to be generated from RPSL specifications.
该工具集还允许根据RPSL规范生成路由器配置。
Editors' Note: The "Internet Routing Registry Toolset" was originally developed by the University of Southern California's Information Sciences Institute (ISI) between 1997 and 2001 as the "Routing Arbiter ToolSet" (RAToolSet) project. The toolset is no longer developed by ISI but is used worldwide, so after a period of improvement by RIPE NCC, it has now been transferred to the Internet Systems Consortium (ISC) for ongoing maintenance as a public resource.
编者注：“Internet路由注册工具集”最初是由南加州大学信息科学研究所（ISI）在1997和2001年间开发的，它是“路由仲裁工具集”（RAToolSet）项目。该工具集不再由ISI开发，而是在全球范围内使用，因此，在经过成熟的NCC一段时间的改进后，它现在已被转移到Internet Systems Consortium（ISC），作为公共资源进行持续维护。
As this is an informational document on the history of requirements in IDR and on the problems facing the current Internet IDR architecture, it does not as such create any security problems. On the other hand, some of the problems with today's Internet routing architecture do create security problems, and these have been discussed in the text above.
由于这是一份关于IDR需求历史和当前互联网IDR体系结构所面临问题的信息性文档，因此不会产生任何安全问题。另一方面，今天的Internet路由架构中的一些问题确实会产生安全问题，这些问题已在上文中讨论过。
The document is derived from work originally produced by Babylon. Babylon was a loose association of individuals from academia, service providers, and vendors whose goal was to discuss issues in Internet routing with the intention of finding solutions for those problems.
该文件来源于最初由巴比伦制作的作品。巴比伦是来自学术界、服务提供商和供应商的松散团体，他们的目标是讨论互联网路由问题，并为这些问题找到解决方案。
The individual members who contributed materially to this document are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.
对本文件作出重大贡献的个人成员有：安德斯·伯格斯滕、霍华德·伯克维茨、马林·卡尔松、伦卡·卡尔·莫蒂科娃、埃尔温·戴维斯、阿夫里·多里亚、皮埃尔·弗兰松、蒋勇、德米特里·克里乌科夫、托夫·马德森、奥勒·珀斯和奥洛夫·舍伦。
Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Susan Hares, Torbjorn Lundberg, David McGrew, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo.
也要感谢巴比伦的成员和其他人，他们对这些材料做了大量的评论。具体而言，我们要感谢以下个人的有益意见和建议：洛亚·安德森、托马斯·艾尔斯特伦、埃里克·阿曼、托马斯·埃里克森、尼古拉斯·博格、奈杰尔·布拉格、托马斯·奇马拉、克里斯特·埃德隆德、奥夫·格拉福德、苏珊·哈雷斯、托比约恩·隆德伯格、大卫·麦格雷夫、贾斯明科·穆拉胡西奇、弗洛里安·丹尼尔·奥特尔、伯恩哈德·斯托克曼、，汤姆·沃斯特和罗伯托·赞帕罗。
In addition, the authors are indebted to the folks who wrote all the references we have consulted in putting this paper together. This includes not only the references explicitly listed below, but also those who contributed to the mailing lists we have been participating in for years.
此外，作者还要感谢那些撰写了我们在撰写本文时参考的所有参考文献的人。这不仅包括下面明确列出的参考资料，还包括那些对我们参与多年的邮件列表作出贡献的人。
The editors thank Lixia Zhang, as IRSG document shepherd, for her help and her perseverance, without which this document would never have been published.
编辑们感谢作为IRSG文件守护者的张丽霞，感谢她的帮助和毅力，没有这些，本文件将永远不会出版。
Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings.
最后，编辑应对任何不清晰、错误、明显的遗漏或误解负责。
[Alaettinoglu00] Alaettinoglu, C., Jacobson, V., and H. Yu, "Towards Milli-Second IGP Convergence", Work in Progress, November 2000.
[Alaettinoglu00]Alaettinoglu，C.，Jacobson，V.，和H.Yu，“迈向毫秒IGP收敛”，正在进行的工作，2000年11月。
[Berkowitz01] Berkowitz, H. and D. Krioukov, "To Be Multihomed: Requirements and Definitions", Work in Progress, July 2001.
[Berkowitz 01]Berkowitz，H.和D.Krioukov，“多宿主：需求和定义”，正在进行的工作，2001年7月。
[Breslau90] Breslau, L. and D. Estrin, "An Architecture for Network-Layer Routing in OSI", Proceedings of the ACM symposium on Communications architectures & protocols , 1990.
[Breslau90]Breslau，L.和D.Estrin，“OSI中网络层路由的体系结构”，通信体系结构与协议ACM研讨会论文集，1990年。
[Chapin94] Piscitello, D. and A. Chapin, "Open Systems Networking: TCP/IP & OSI", Addison-Wesley Copyright assigned to authors, 1994, <http://www.interisle.net/OSN/OSN.html>.
[Chapin94]Piscitello，D.和A.Chapin，“开放系统网络：TCP/IP和OSI”，Addison-Wesley版权归作者所有，1994年<http://www.interisle.net/OSN/OSN.html>.
[Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress, 1991.
[Chiappa91]Chiappa，J.，“一种新的IP路由和寻址架构”，正在进行的工作，1991年。
[Clark00] Clark, D. and M. Blumenthal, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", August 2000, <http://dspace.mit.edu/handle/1721.1/1519>.
[Clark00]Clark，D.和M.Blumenthal，“重新思考互联网的设计：端到端的争论与勇敢的新世界”，2000年8月<http://dspace.mit.edu/handle/1721.1/1519>.
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", Association for Computing Machinery Proceedings of SIGCOMM '99, 1999.
[Griffin 99]Griffin，T.和G.Wilfong，“BGP收敛特性的分析”，计算机械协会学报，SIGCOMM'99，1999年。
[Huitema90] Huitema, C. and W. Dabbous, "Routeing protocols development in the OSI architecture", Proceedings of ISCIS V Turkey, 1990.
[Huitema 90]Huitema，C.和W.Dabbous，“OSI体系结构中的路由协议开发”，ISCIS诉土耳其会议录，1990年。
[Huston05] Huston, G., "Exploring Autonomous System Numbers", The ISP Column , August 2005, <http://www.potaroo.net/ispcol/2005-08/as.html>.
[Huston05]Huston，G.，“探索自主系统编号”，ISP专栏，2005年8月<http://www.potaroo.net/ispcol/2005-08/as.html>.
[INARC89] Mills, D., Ed. and M. Davis, Ed., "Internet Architecture Workshop: Future of the Internet System Architecture and TCP/IP Protocols - Report", Internet Architecture Task Force INARC, 1990, <http://www.eecis.udel.edu/~mills/ database/papers/inarc.pdf>.
[INARC89]Mills，D.，Ed.和M.Davis，Ed.，“互联网架构研讨会：互联网系统架构和TCP/IP协议的未来-报告”，互联网架构工作组INARC，1990年<http://www.eecis.udel.edu/~mills/database/papers/inarc.pdf>。
[IRRToolSet] Internet Systems Consortium, "Internet Routing Registry Toolset Project", IRR Tool Set Website, 2006, <http://www.isc.org/index.pl?/sw/IRRToolSet/>.
[IRRToolSet]互联网系统联盟，“互联网路由注册工具集项目”，IRR工具集网站，2006年<http://www.isc.org/index.pl?/sw/IRRToolSet/>.
[ISO10747] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs", International Standard 10747 , 1993.
[ISO10747]ISO/IEC，“支持ISO 8473 PDU转发的中间系统间域间路由信息交换协议”，国际标准10747，1993年。
[Jiang02] Jiang, Y., Doria, A., Olsson, D., and F. Pettersson, "Inter-domain Routing Stability Measurement", 2002, <http://psg.com/~avri/papers/paper-yong-hpsr2002-final.pdf>.
[Jiang02]Jiang，Y.，Doria，A.，Olsson，D.，和F.Pettersson，“域间路由稳定性度量”，2002年<http://psg.com/~avri/papers/paper-yong-hpsr2002-final.pdf>。
[Katz10] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, January 2010.
[Katz10]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2010年1月。
[Labovitz02] Labovitz, C., Ahuja, A., Farnam, J., and A. Bose, "Experimental Measurement of Delayed Convergence", NANOG , 2002.
[Labovitz02]Labovitz，C.，Ahuja，A.，Farnam，J.，和A.Bose，“延迟收敛的实验测量”，NANOG，2002年。
[NewArch03] Clark, D., Sollins, K., Wroclawski, J., Katabi, D., Kulik, J., Yang, X., Braden, R., Faber, T., Falk, A., Pingali, V., Handley, M., and N. Chiappa, "New Arch: Future Generation Internet Architecture", December 2003, <http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>.
[NewArch03]Clark，D.，Sollins，K.，Wroclawski，J.，Katabi，D.，Kulik，J.，Yang，X.，Braden，R.，Faber，T.，Falk，A.，Pingali，V.，Handley，M.，和N.Chiappa，“新拱门：未来一代互联网架构”，2003年12月<http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>.
[RFC0904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC0904]Mills，D.，“外部网关协议正式规范”，RFC 904，1984年4月。
[RFC0975] Mills, D., "Autonomous confederations", RFC 975, February 1986.
[RFC0975]Mills，D.，“自治联合会”，RFC 975，1986年2月。
[RFC1105] Lougheed, K. and J. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105]Lougheed，K.和J.Rekhter，“边界网关协议（BGP）”，RFC1105，1989年6月。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126]Little，M.“自治系统间路由的目标和功能要求”，RFC1126，1989年10月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1163，1990年6月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267]Lougheed，K.和Y.Rekhter，“边境网关协议3（BGP-3）”，RFC 1267，1991年10月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752]Bradner，S.和A.Mankin，“IP下一代协议的建议”，RFC 1752，1995年1月。
[RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753]Chiapa，J.，“Nimrod路由和寻址体系结构的IPng技术要求”，RFC 1753，1994年12月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992]Castineyra，I.，Chiapa，N.，和M.Steenstrup，“Nimrod路由架构”，RFC 1992，1996年8月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，和V.Jacobson，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 26221999年6月。
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, August 1999.
[RFC2650]Meyer，D.，Schmitz，J.，Orange，C.，Prior，M.，和C.Alaettinoglu，“在实践中使用RPSL”，RFC 2650，1999年8月。
[RFC2791] Yu, J., "Scalable Routing Design Principles", RFC 2791, July 2000.
[RFC2791]Yu，J.，“可扩展路由设计原则”，RFC 27912000年7月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，G.“互联网中域间路由的评论”，RFC3221，2001年12月。
[RFC3277] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[RFC3277]McPherson，D.，“中间系统对中间系统（IS-IS）瞬态黑洞回避”，RFC3277，2002年4月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345]McPherson，D.，Gill，V.，Walton，D.，和A.Retana，“边界网关协议（BGP）持续路由振荡条件”，RFC 33452002年8月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC3765]Huston，G.“用于边界网关协议（BGP）路由范围控制的NOPEER社区”，RFC 3765，2004年4月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913]Thaler，D.，“边界网关多播协议（BGMP）：协议规范”，RFC 3913，2004年9月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116]Abley，J.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 41162005年7月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 47242007年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893]Vohra，Q.和E.Chen，“BGP支持四个八位组作为数字空间”，RFC 4893，2007年5月。
[RFC5772] Doria, A., Davies, E., and F. Kastenholz, "A Set of Possible Requirements for a Future Routing Architecture", RFC 5772, February 2010.
[RFC5772]Doria，A.，Davies，E.，和F.Kastenholz，“未来路由架构的一组可能要求”，RFC 57722010年2月。
[Sandiick00] Sandick, H., Squire, M., Cain, B., Duncan, I., and B. Haberman, "Fast LIveness Protocol (FLIP)", Work in Progress, February 2000.
[Sandiick00]Sandick，H.，Squire，M.，Cain，B.，Duncan，I.，和B.Haberman，“快速活性协议（FLIP）”，正在进行的工作，2000年2月。
[Tsuchiya87] Tsuchiya, P., "An Architecture for Network-Layer Routing in OSI", Proceedings of the ACM workshop on Frontiers in computer communications technology , 1987.
[Tsuchiya87]Tsuchiya，P.，“OSI中网络层路由的架构”，计算机通信技术前沿ACM研讨会论文集，1987年。
[Xu97] Xu, Z., Dai, S., and J. Garcia-Luna-Aceves, "A More Efficient Distance Vector Routing Algorithm", Proc IEEE MILCOM 97, Monterey, California, Nov 1997, <http:// www.cse.ucsc.edu/research/ccrg/publications/ zhengyu.milcom97.pdf>.
[Xu97]Xu，Z.，Dai，S.，和J.Garcia Luna Aceves，“一种更有效的距离向量路由算法”，IEEE MILCOM 97程序，加利福尼亚州蒙特雷，1997年11月，<http://www.cse.ucsc.edu/research/ccrg/publications/zhengyu.milcom97.pdf>。
Authors' Addresses
作者地址
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B.Davies Folly Consulting Soham，英国剑桥
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Avri Doria LTU Lulea, 971 87 Sweden
Avri Doria LTU Lulea，971 87瑞典
Phone: +1 401 663 5024
EMail: avri@acm.org
Phone: +1 401 663 5024
EMail: avri@acm.org