Internet Engineering Task Force (IETF) A. Retana
Request for Comments: 6987 L. Nguyen
Obsoletes: 3137 Cisco Systems, Inc.
Category: Informational A. Zinin
ISSN: 2070-1721 Cinarra Systems
R. White
Internet Engineering Task Force (IETF) A. Retana
Request for Comments: 6987 L. Nguyen
Obsoletes: 3137 Cisco Systems, Inc.
Category: Informational A. Zinin
ISSN: 2070-1721 Cinarra Systems
R. White
D. McPherson Verisign, Inc. September 2013
D.麦克弗森Verisign公司，2013年9月
OSPF Stub Router Advertisement
OSPF存根路由器广告
Abstract
摘要
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.
本文档描述了一种向后兼容的技术，OSPF（开放最短路径优先）实现可使用该技术来通告路由器的不可用性，以转发传输流量或降低通过该路由器的路径的首选级别。
This document obsoletes RFC 3137.
本文件淘汰了RFC 3137。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6987.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6987.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv3-Only Solution . . . . . . . . . . . . . . . . . . 3
3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Changes from RFC 3137 . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv3-Only Solution . . . . . . . . . . . . . . . . . . 3
3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Changes from RFC 3137 . . . . . . . . . . . . . . . 6
In some situations, it may be advantageous to inform routers in a network not to use a specific router as a transit point but to still route to it. Possible situations include the following:
在某些情况下，通知网络中的路由器不要使用特定路由器作为中转点，而是仍然路由到它可能是有利的。可能的情况包括：
o The router is in a critical condition (for example, has a very high CPU load or does not have enough memory to store all Link State Advertisements (LSAs) or build the routing table).
o 路由器处于关键状态（例如，CPU负载非常高，或者没有足够的内存来存储所有链路状态播发（LSA）或构建路由表）。
o Graceful introduction and removal of the router to/from the network.
o 在网络中优雅地引入和移除路由器。
o Other (administrative or traffic engineering) reasons.
o 其他（行政或交通工程）原因。
Note that the solution introduced in this document does not remove the router from the topology view of the network (as could be done by just flushing that router's router-LSA) but discourages other routers from using it for transit routing, while still routing packets to the router's own IP addresses, i.e., the router is announced as a stub.
请注意，本文档中介绍的解决方案不会将路由器从网络拓扑视图中移除（只需刷新该路由器的路由器LSA即可），但会阻止其他路由器将其用于传输路由，同时仍将数据包路由到路由器自己的IP地址，即，路由器被宣布为存根。
It must be emphasized that the solution provides real benefits in networks designed with at least some level of redundancy, so that traffic can be routed around the stub router. Otherwise, traffic destined for the networks and reachable through such a stub router may still be routed through it.
必须强调的是，该解决方案在设计为至少具有某种程度冗余的网络中提供了真正的好处，因此可以在存根路由器周围路由流量。否则，目的地为网络且可通过这样的存根路由器到达的业务仍然可以通过它路由。
The solution introduced in this document solves two challenges associated with the outlined problem. In the description below, router X is the router announcing itself as a stub. The challenges are
本文档中介绍的解决方案解决了与概述的问题相关的两个难题。在下面的描述中，路由器X是宣布自己为存根的路由器。挑战是
1) Making other routers prefer routes around router X while performing the Dijkstra calculation.
1) 在执行Dijkstra计算时，使其他路由器优先选择路由器X周围的路由。
2) Allowing other routers to reach IP prefixes directly connected to router X.
2) 允许其他路由器访问直接连接到路由器X的IP前缀。
Note that it would be easy to address issue 1) alone by just flushing router X's router-LSA from the domain. However, it does not solve problem 2), since other routers will not be able to use links to router X in Dijkstra (no back link), and because router X will not have links to its neighbors.
请注意，只需从域中刷新路由器X的路由器LSA，就可以轻松解决问题1）。然而，这并不能解决问题2），因为其他路由器将无法使用到Dijkstra中路由器X的链路（无反向链路），并且因为路由器X将没有到其邻居的链路。
To address both problems, router X announces its router-LSA to the neighbors with the cost of all non-stub links (links of the types other than 3) being set to MaxLinkMetric (defined in Section 3).
为了解决这两个问题，路由器X向邻居宣布其路由器LSA，并将所有非存根链路（3以外类型的链路）的成本设置为MaxLinkMetric（定义见第3节）。
The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].
上述解决方案适用于OSPFv2[RFC2328]和OSPFv3[RFC5340]。
OSPFv3 [RFC5340] introduces additional options to provide similar control of the forwarding topology; the R-bit provides an indication of whether a router is active and should be used for transit traffic.
OSPFv3[RFC5340]引入了其他选项，以提供对转发拓扑的类似控制；R位提供路由器是否处于活动状态以及是否应用于传输流量的指示。
It is left to network operators to decide which technique to use in their network. See Section 4 for more details.
由网络运营商决定在其网络中使用哪种技术。详见第4节。
Section 2 refers to the cost of all non-stub links as MaxLinkMetric, which is a new fixed architectural value introduced in this document.
第2节将所有非存根链接的成本称为MaxLinkMetric，这是本文档中引入的一个新的固定体系结构值。
MaxLinkMetric The metric value indicating that a router-LSA link (see Section 2) should not be used for transit traffic. It is defined to be the 16-bit binary value of all ones: 0xffff.
MaxLinkMetric表示路由器LSA链路（见第2节）不应用于传输流量的度量值。它被定义为所有值的16位二进制值：0xffff。
When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform an intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path.
当使用MaxLinkMetric时，如果网络由执行[RFC1247]中规定的区域内Dijkstra计算的路由器（丢弃具有MaxLinkMetric成本值的路由器LSA中的链路记录）和执行[RFC1583]中规定的以及更高版本的路由器构成，则可能会出现一些不一致（不要将具有MaxLinkMetric成本的链接视为无法访问）。请注意，这种不一致性不会导致路由循环，因为如果网络中存在一些备用路径，则两种类型的路由器将同意使用它们，而不是通过存根路由器的路径。如果通过存根路由器的路径是唯一的路径，则第一种类型的路由器将不使用存根路由器进行传输（这是所需的行为），而第二种类型的路由器仍将使用此路径。
On the other hand, clearing the R-bit will consistently result in the router not being used for transit.
另一方面，清除R位将始终导致路由器不用于传输。
The use of MaxLinkMetric or the R-bit in a network depends on the objectives of the operator. One of the possible considerations for selecting one or the other is in the desired behavior if the path through the stub router is the only one available. Using MaxLinkMetric allows for that path to be used while the R-bit doesn't.
网络中MaxLinkMetric或R位的使用取决于操作员的目标。如果通过存根路由器的路径是唯一可用的路径，那么选择一个或另一个的可能考虑因素之一是期望的行为。使用MaxLinkMetric允许使用该路径，而R位不允许。
The technique described in this document does not introduce any new security issues into the OSPF protocol.
本文档中描述的技术不会在OSPF协议中引入任何新的安全问题。
The authors of this document do not make any claims on the originality of the ideas described. Among other people, we would like to acknowledge Henk Smit for being part of one of the initial discussions around this topic.
本文件的作者不对所述想法的独创性提出任何主张。在其他人中，我们要感谢Henk Smit参与了围绕这一主题的初步讨论。
We would like to thank Shishio Tsuchiya, Gunter Van de Velde, Tomohiro Yamagata, Faraz Shamim, and Acee Lindem who provided significant input for the latest draft version of this document. Dave Cridland and Tom Yu also provided valuable comments.
我们要感谢筑屋世雄、Gunter Van de Velde、山形智博、Faraz Shamim和Acee Lindem，他们为本文件的最新草案提供了重要的投入。Dave Cridland和Tom Yu也提供了宝贵的意见。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[RFC1247]莫伊，J.，“OSPF版本2”，RFC1247，1991年7月。
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC1583]莫伊，J.，“OSPF版本2”，RFC1583，1994年3月。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137]Retana，A.，Nguyen，L.，White，R.，Zinin，A.，和D.McPherson，“OSPF存根路由器广告”，RFC 3137，2001年6月。
This document obsoletes [RFC3137].
本文件废除了[RFC3137]。
In addition to editorial updates, this document defines a new architectural constant (MaxLinkMetric in Section 3) to eliminate any confusion about the interpretation of LSInfinity. It also incorporates and explains the use of the R-bit [RFC5340] as a solution to the problem addressed in the text.
除编辑性更新外，本文件还定义了一个新的体系结构常数（第3节中的MaxLinkMetric），以消除对LSInfinity解释的任何混淆。它还结合并解释了使用R位[RFC5340]作为文本中所述问题的解决方案。
Authors' Addresses
作者地址
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
阿尔瓦罗·雷塔纳思科系统公司，地址：美国北卡罗来纳州三角研究园基特克里克路7025号，邮编：27709
EMail: aretana@cisco.com
EMail: aretana@cisco.com
Liem Nguyen Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 USA
Liem Nguyen Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科路3750号，邮编95134
EMail: lhnguyen@cisco.com
EMail: lhnguyen@cisco.com
Alex Zinin Cinarra Systems Menlo Park, CA USA
Alex Zinin Cinarra Systems Menlo Park，加利福尼亚州，美国
EMail: alex.zinin@gmail.com
EMail: alex.zinin@gmail.com
Russ White 1500 N. Greenville Avenue Suite 1100 Richardson, TX 75081 USA
美国德克萨斯州理查森市格林维尔大道北1500号Russ White 1100套房，邮编75081
EMail: Russ.White@vce.com
EMail: Russ.White@vce.com
Danny McPherson Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 USA
Danny McPherson Verisign，Inc.美国弗吉尼亚州布鲁蒙特路莱斯顿12061号，邮编：20190
EMail: dmcpherson@verisign.com
EMail: dmcpherson@verisign.com