Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 8042 L. Wang
Updates: 2328 Juniper Networks, Inc.
Category: Standards Track A. Lindem
ISSN: 2070-1721 Cisco Systems
December 2016
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 8042 L. Wang
Updates: 2328 Juniper Networks, Inc.
Category: Standards Track A. Lindem
ISSN: 2070-1721 Cisco Systems
December 2016
OSPF Two-Part Metric
两部分度量
Abstract
摘要
This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.
本文档指定了可选的OSPF协议扩展，以将多址网络中的路由器度量分为两部分：从路由器到网络的度量和从网络到路由器的度量。对于此类网络，OSPF路由计算的路由器到路由器度量是这两部分的总和。本文档更新了RFC 2328。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8042.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8042.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4
3.3. Advertising Network-to-Router Traffic Engineering (TE)
Metric . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4
3.3. Advertising Network-to-Router Traffic Engineering (TE)
Metric . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
With Open Shortest Path First (OSPF) [RFC2328] [RFC5340]), a Network-LSA (Link State Advertisement) is advertised to list all routers on a broadcast network. Additionally, each router on the broadcast network includes a link in its Router-LSA to describe its connection to the network. The link in the Router-LSA includes a metric but the listed routers in the Network-LSA do not include a metric. This is based on the assumption that from a particular router, all others on the same network can be reached with the same metric.
使用开放最短路径优先（OSPF）[RFC2328][RFC5340]），网络LSA（链路状态公告）被公告以列出广播网络上的所有路由器。此外，广播网络上的每个路由器在其路由器LSA中包括链路以描述其到网络的连接。路由器LSA中的链路包括度量，但是网络LSA中列出的路由器不包括度量。这是基于这样一个假设，即从一个特定的路由器，同一网络上的所有其他路由器都可以使用相同的度量。
With some broadcast networks, different routers can be reached with different metrics. [RFC6845] extends the OSPF protocol with a hybrid interface type for that kind of broadcast network, where no Network-LSA is advertised and Router-LSAs simply include point-to-point links to all routers on the same network with individual metrics. Broadcast capability is still used to optimize database synchronization and adjacency maintenance.
在某些广播网络中，可以使用不同的度量到达不同的路由器。[RFC6845]为这种广播网络扩展了OSPF协议，采用了混合接口类型，在这种网络中，没有公布网络LSA，路由器LSA仅包括到同一网络上具有单独指标的所有路由器的点对点链路。广播功能仍然用于优化数据库同步和邻接维护。
This works well for broadcast networks where the metric between different pairs of routers are really independent, for example, Virtual Private LAN Service (VPLS) networks.
这适用于不同路由器对之间的度量真正独立的广播网络，例如，虚拟专用LAN服务（VPLS）网络。
With certain types of broadcast networks, further optimization can be made to reduce the size of Router-LSAs and the number of updates.
对于某些类型的广播网络，可以进行进一步优化，以减少路由器LSA的大小和更新的次数。
Consider a satellite radio network with fixed and mobile ground terminals. All communication goes through the satellite. When the mobile terminals move about, their communication capability may change. When OSPF runs over the radio network, [RFC6845] hybrid interface can be used, but with the following drawbacks.
考虑具有固定和移动地面终端的卫星无线电网络。所有的通讯都通过卫星进行。当移动终端移动时，它们的通信能力可能会改变。当OSPF在无线网络上运行时，可以使用[RFC6845]混合接口，但有以下缺点。
Consider that one terminal/router moves into an area where its communication capability degrades significantly. Through the radio control protocol, all other routers determine that the metric to this particular router changed and they all need to update their Router-LSAs accordingly. In addition, the router in question determines that its metric to reach all others also changed and it needs to update its Router-LSA. Consider that there could be many terminals and many of them can be moving fast and frequently. The number and frequency of updates of those large Router-LSAs could inhibit network scaling.
考虑到一个终端/路由器移动到其通信能力显著降低的区域。通过无线电控制协议，所有其他路由器确定该特定路由器的度量已更改，并且它们都需要相应地更新其路由器LSA。此外，所讨论的路由器确定其到达所有其他路由器的度量也发生了变化，需要更新其路由器LSA。考虑到可能有很多终端，其中许多终端可以快速和频繁地移动。这些大型路由器LSA的更新次数和频率可能会抑制网络扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Notice that in the above scenario, when one terminal's communication capability changes, its metric to all other terminals and the metric to it from all other terminals will all change in a similar fashion. Given this, the above problem can be easily addressed by breaking the metric into two parts: the metric to the satellite and the metric from the satellite. The metric from terminal R1 to R2 would be the sum of the metric from R1 to the satellite and the metric from the satellite to R2.
请注意，在上述场景中，当一个终端的通信能力发生变化时，其对所有其他终端的度量以及所有其他终端对其的度量都将以类似的方式发生变化。有鉴于此，可以通过将度量分为两部分来轻松解决上述问题：到卫星的度量和来自卫星的度量。从终端R1到R2的度量是从R1到卫星的度量和从卫星到R2的度量之和。
Instead of using the hybrid interface type described in [RFC6845], the network is treated as a regular broadcast network. A router on the network no longer lists individual metrics to each neighbor in its Router-LSA. Instead, each router advertises the metric from the network to itself in addition to the normal metric for the network. With the normal Router-to-Network and additional Network-to-Router metrics advertised for each router, individual Router-to-Router metrics can be calculated.
与[RFC6845]中所述的混合接口类型不同，该网络被视为常规广播网络。网络上的路由器不再向其路由器LSA中的每个邻居列出单个度量。相反，除了网络的正常度量之外，每个路由器还将度量从网络播发到自身。通过为每个路由器公布的普通路由器到网络和额外的网络到路由器度量，可以计算单个路由器到路由器度量。
With the proposed enhancement, the size of the Router-LSA will be significantly reduced. In addition, when a router's communication capability changes, only that router needs to update its Router-LSA.
通过建议的增强，路由器LSA的大小将显著减小。此外，当路由器的通信能力发生变化时，只有该路由器需要更新其路由器LSA。
Note that while the example uses the satellite as the relay point at the radio level (layer 2), the satellite does not participate in packet forwarding at layer 3. In fact, the satellite does not need to run any layer-3 protocol. Therefore, for generality, the metric is abstracted as to/from the "network" rather than specifically to/ from the "satellite".
注意，虽然示例使用卫星作为无线电级别（第2层）的中继点，但卫星不参与第3层的分组转发。事实上，卫星不需要运行任何第三层协议。因此，为了通用性，度量被抽象为与“网络”相关的度量，而不是专门与“卫星”相关的度量。
The following specifications are added to or modified from the base OSPF protocol. If an area contains one or more two-part metric networks, then all routers in the area MUST support the extensions specified herein. This is ensured by procedures described in Section 3.7.
在基本OSPF协议中添加或修改了以下规范。如果一个区域包含一个或多个由两部分组成的度量网络，则该区域中的所有路由器都必须支持此处指定的扩展。第3.7节中所述的程序可确保这一点。
The "Router interface parameters" have the following additions:
“路由器接口参数”增加了以下内容：
o Two-part metric: TRUE if the interface connects to a multi-access network that uses a two-part metric. All routers connected to the same network SHOULD have the same configuration for their corresponding interfaces.
o 两部分指标：如果接口连接到使用两部分指标的多址网络，则为TRUE。连接到同一网络的所有路由器的相应接口应具有相同的配置。
o Interface input cost: Link-state metric from the two-part-metric network to this router. Defaults to "Interface output cost" but is not valid for normal networks using a single metric. May be configured or dynamically adjusted to a value different from the "Interface output cost".
o 接口输入成本：从两部分度量网络到该路由器的链路状态度量。默认为“接口输出成本”，但对于使用单个指标的正常网络无效。可以配置或动态调整为不同于“接口输出成本”的值。
For OSPFv2, the Network-to-Router metric is encoded in an OSPF Extended Link TLV Sub-TLV [RFC7684], defined in this document as the Network-to-Router Metric Sub-TLV. The type of the sub-TLV is 4. The length of the sub-TLV is 4 (for the value part only). The value part of the sub-TLV is defined as follows:
对于OSPFv2，网络到路由器度量编码在OSPF扩展链路TLV子TLV[RFC7684]中，在本文件中定义为网络到路由器度量子TLV。子TLV的类型为4。子TLV的长度为4（仅限数值部分）。子TLV的值部分定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple such sub-TLVs can exist in a single OSPF Extended Link TLV, one for each topology [RFC4915]. Each sub-TLV will have a unique Multi-Topology Identifier (MT-ID) and will adhere to the advertisement rules defined in Section 3.4 of [RFC4915]. The OSPF
在单个OSPF扩展链路TLV中可以存在多个这样的子TLV，每个拓扑一个[RFC4915]。每个子TLV将具有唯一的多拓扑标识符（MT-ID），并将遵守[RFC4915]第3.4节中定义的公告规则。OSPF
Extended Link TLV identifies the transit link to the network and is part of an OSPFv2 Extended-Link Opaque LSA. The sub-TLV MUST ONLY appear in Extended-Link TLVs for Link Type 2 (link to transit network) and MUST be ignored if received for other link types.
扩展链路TLV标识到网络的传输链路，是OSPFv2扩展链路不透明LSA的一部分。对于链路类型2（链路到传输网络），子TLV必须仅出现在扩展链路TLV中，并且如果接收到其他链路类型，则必须忽略子TLV。
A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, similar to the Traffic Engineering Metric Sub-TLV defined in Section 2.5.5 of [RFC3630]. The only difference is the TLV type, which is 35. The sub-TLV MUST only appear in Type 2 Link TLVs (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs (OSPFv3) [RFC5329], and MUST appear at most once in such a Link TLV.
定义了流量工程网络到路由器度量子TLV，类似于[RFC3630]第2.5.5节中定义的流量工程度量子TLV。唯一的区别是TLV类型，即35。子TLV必须仅出现在流量工程师LSA（OSPF2）或区域内TE LSA（OSPFv3）[RFC5329]的类型2链路TLV（多址）中，并且必须在此类链路TLV中最多出现一次。
Network-to-Router metric advertisement in OSPFv3 Extended Router-LSA [OSPFV3-EXTENDED-LSA] will be described in a separate document.
OSPFv3扩展路由器LSA[OSPFv3-Extended-LSA]中的网络到路由器度量广告将在单独的文档中描述。
When an OSPF router with interfaces to multi-access networks using two-part metrics is advertising itself as a stub router [RFC6987], only the Router-to-Network metric in the stub router's OSPF Router-LSA links for those networks is set to the MaxLinkMetric. This is fully backward compatible and will result in the same behavior as described in [RFC6987].
当一个OSPF路由器与使用两部分指标的多址网络接口作为存根路由器进行自我宣传[RFC6987]时，只有存根路由器的OSPF路由器LSA链路中用于这些网络的路由器到网络指标设置为MaxLinkMetric。这是完全向后兼容的，并将产生与[RFC6987]中所述相同的行为。
The first stage of the shortest-path tree calculation is described in Section 16.1 of [RFC2328]. With a two-part metric, when a vertex V corresponding to a Network-LSA has just been added to the Shortest Path Tree (SPT) and an adjacent vertex W (joined by a link in V's corresponding Network-LSA) is being added to the candidate list, the cost from V to W (W's network-to-router cost) is determined as follows:
[RFC2328]第16.1节描述了最短路径树计算的第一阶段。对于两部分度量，当与网络LSA对应的顶点V刚刚被添加到最短路径树（SPT）并且相邻顶点W（由V的对应网络LSA中的链接连接）被添加到候选列表时，从V到W的成本（W的网络到路由器成本）确定如下：
o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque LSA with an Extended Link TLV for the link from W to V, and the Extended Link TLV has a Network-to-Router Metric Sub-TLV for the corresponding topology, then the cost from V to W is the metric in the sub-TLV. Otherwise, the cost is 0.
o 对于OSPFv2，如果顶点W具有相应的扩展链路不透明LSA，对于从W到V的链路具有扩展链路TLV，并且扩展链路TLV具有对应拓扑的网络到路由器度量子TLV，则从V到W的成本是子TLV中的度量。否则，成本为0。
o OSPFv3 [RFC5340] Shortest Path First (SPF) changes will be described in a separate document.
o OSPFv3[RFC5340]最短路径优先（SPF）变更将在单独的文件中描述。
Due to the change of procedures in the SPF calculation, all routers in an area that includes one or more two-part metric networks must support the changes specified in this document. To ensure that, if an area is provisioned to support two-part metric networks, all routers supporting this capability must advertise a Router Information (RI) LSA with a Router Functional Capabilities TLV [RFC7770] that includes the following Router Functional Capability Bit:
由于SPF计算过程的变更，包含一个或多个两部分公制网络的区域内的所有路由器必须支持本文件中规定的变更。为了确保，如果一个区域被配置为支持两部分度量网络，则所有支持此功能的路由器必须使用路由器功能TLV[RFC7770]播发路由器信息（RI）LSA，该路由器功能TLV[RFC7770]包括以下路由器功能位：
Bit Capabilities
比特能力
6 Two-Part Metric support
6两部分公制支架
Upon detecting the presence of a reachable Router-LSA without a companion RI LSA that has the bit set, all routers MUST recalculate routes without considering any network-to-router costs.
在检测到存在一个可到达的路由器LSA，而没有一个具有该位集的伴随RI LSA时，所有路由器必须重新计算路由，而不考虑任何网络到路由器的成本。
IANA has made the following assignments per this document:
IANA已根据本文件完成以下任务：
o Two-Part Metric support (6) was added to the "OSPF Router Informational Capability Bits" registry.
o “OSPF路由器信息能力位”注册表中添加了两部分度量支持（6）。
o Network-to-Router Metric Sub-TLV (4) has been added to the "OSPFv2 Extended Link TLV Sub-TLVs" registry.
o 网络到路由器度量子TLV（4）已添加到“OSPFv2扩展链路TLV子TLV”注册表中。
o Network-to-Router TE Metric Sub-TLV (35) has been added to the "Types for sub-TLVs of TE Link TLV (Value 2)" registry.
o 网络到路由器TE度量子TLV（35）已添加到“TE链路TLV子TLV类型（值2）”注册表中。
This document does not introduce new security risks. Existing security considerations in OSPFv2 and OSPFv3 apply.
本文件不会引入新的安全风险。OSPFv2和OSPFv3中的现有安全注意事项适用。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<http://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，DOI 10.17487/RFC4915，2007年6月<http://www.rfc-editor.org/info/rfc4915>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <http://www.rfc-editor.org/info/rfc5329>.
[RFC5329]Ishiguro，K.，Manral，V.，Davey，A.，和A.Lindem，Ed.，“OSPF版本3的流量工程扩展”，RFC 5329，DOI 10.17487/RFC5329，2008年9月<http://www.rfc-editor.org/info/rfc5329>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7684]Psenak，P.，Gredler，H.，Shakir，R.，Henderickx，W.，Tantsura，J.，和A.Lindem，“OSPFv2前缀/链接属性广告”，RFC 7684，DOI 10.17487/RFC7684，2015年11月<http://www.rfc-editor.org/info/rfc7684>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7770]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 7770，DOI 10.17487/RFC7770，2016年2月<http://www.rfc-editor.org/info/rfc7770>.
[OSPFV3-EXTENDED-LSA] Lindem, A., Mirtorabi, S., and A. Roy, "OSPFv3 LSA Extendibility", Work in Progress, draft-ietf-ospf-ospfv3- lsa-extend-13.txt, October 2016.
[OSPFV3-EXTENDED-LSA]Lindem，A.，Mirtorabi，S.，和A.Roy，“OSPFV3-LSA可扩展性”，正在进行的工作，草稿-ietf-ospf-OSPFV3-LSA-extend-13.txt，2016年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, <http://www.rfc-editor.org/info/rfc6845>.
[RFC6845]Sheth，N.，Wang，L.，和J.Zhang，“OSPF混合广播和点对多点接口类型”，RFC 6845，DOI 10.17487/RFC6845，2013年1月<http://www.rfc-editor.org/info/rfc6845>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[RFC6987]Retana，A.，Nguyen，L.，Zinin，A.，White，R.，和D.McPherson，“OSPF存根路由器广告”，RFC 6987，DOI 10.17487/RFC6987，2013年9月<http://www.rfc-editor.org/info/rfc6987>.
Acknowledgements
致谢
The authors would like to thank Abhay Roy, Hannes Gredler, Peter Psenak, and Eric Wu for their comments and suggestions.
作者要感谢Abhay Roy、Hannes Gredler、Peter Psenak和Eric Wu的评论和建议。
Contributors
贡献者
David Dubois General Dynamics C4S 400 John Quincy Adams Road Taunton, MA 02780 United States of America Email: dave.dubois@gd-ms.com
David Dubois General Dynamics C4S 400马萨诸塞州汤顿市约翰·昆西·亚当斯路02780美利坚合众国电子邮件：dave。dubois@gd-ms.com
Vibhor Julka Individual Contributor
Vibhor Julka个人投稿人
Email: vjulka1@yahoo.com
Email: vjulka1@yahoo.com
Tom McMillan L3 Communications, Linkabit 9890 Towne Centre Drive San Diego, CA 92121 United States of America Email: tom.mcmillan@l-3com.com
Tom McMillan L3 Communications，地址：美国加利福尼亚州圣地亚哥市汤恩中心路9890号，邮编：92121电子邮件：Tom。mcmillan@l-3com.com
Authors' Addresses
作者地址
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号张昭辉Juniper Networks，Inc.01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net
Lili Wang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Lili Wang Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: liliw@juniper.net
Email: liliw@juniper.net
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem思科系统301美国北卡罗来纳州米登霍尔大道卡里27513号
Email: acee@cisco.com
Email: acee@cisco.com