Internet Engineering Task Force (IETF) P. Psenak, Ed.
Request for Comments: 8510 K. Talaulikar
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 W. Henderickx
Nokia
P. Pillay-Esnault
Huawei USA
January 2019
Internet Engineering Task Force (IETF) P. Psenak, Ed.
Request for Comments: 8510 K. Talaulikar
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 W. Henderickx
Nokia
P. Pillay-Esnault
Huawei USA
January 2019
OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
用于本地接口ID播发的OSPF链路本地信令（LLS）扩展
Abstract
摘要
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).
每个OSPF接口都分配了一个接口ID，唯一地标识路由器上的接口。在某些情况下，了解邻接的远程端分配的接口ID（远程接口ID）非常有用。
This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.
本文档描述了OSPF链路本地信令（LLS）的扩展，以公布本地接口ID。
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 https://www.rfc-editor.org/info/rfc8510.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8510.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4
1.2. Requirements Language ......................................4
2. Interface ID Exchange Using OSPF LLS ............................4
2.1. Local Interface ID TLV .....................................5
3. Backward Compatibility with RFC 4203 ............................5
4. IANA Considerations .............................................6
5. Security Considerations .........................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction ....................................................3
1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4
1.2. Requirements Language ......................................4
2. Interface ID Exchange Using OSPF LLS ............................4
2.1. Local Interface ID TLV .....................................5
3. Backward Compatibility with RFC 4203 ............................5
4. IANA Considerations .............................................6
5. Security Considerations .........................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. [RFC2328] uses this Interface ID in the Router Link State Advertisement (Router-LSA) Link Data for unnumbered links and uses the value of the MIB-II ifIndex [RFC2863]. [RFC4203] refers to these Interface IDs as the Link Local/Remote Identifiers and defines a way to advertise and use them for GMPLS purposes. [RFC8379] defines a way to advertise Local/ Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA.
每个OSPF接口都分配了一个接口ID，唯一地标识路由器上的接口。[RFC2328]在路由器链路状态公告（路由器LSA）链路数据中为未编号的链路使用此接口ID，并使用MIB-II ifIndex[RFC2863]的值。[RFC4203]将这些接口ID称为链路本地/远程标识符，并定义了为GMPLS目的发布和使用它们的方法。[RFC8379]定义了在OSPFv2扩展链路不透明LSA中公布本地/远程接口ID的方法。
There is a known OSPFv2 protocol problem in verifying the bidirectional connectivity with parallel unnumbered links. If there are two parallel unnumbered links between a pair of routers and each link is only advertised from a single direction, such two unidirectional parallel links could be considered as a valid single bidirectional link during the OSPF route computation on some other router. If each link is advertised with both its Local and Remote Interface IDs, the advertisement of each link from both sides of adjacency can be verified by cross-checking the Local and Remote Interface IDs of both advertisements.
在验证具有并行无编号链路的双向连接时，存在已知的OSPFv2协议问题。如果一对路由器之间存在两个并行的未编号链路，并且每个链路仅从一个方向播发，则在某些其他路由器上的OSPF路由计算期间，这两个单向并行链路可被视为有效的单个双向链路。如果每个链路都使用其本地和远程接口ID播发，则可以通过交叉检查两个播发的本地和远程接口ID来验证相邻两侧的每个链路的播发。
From the perspective of the advertising router, the Local Interface ID is a known value. However, the Remote Interface ID needs to be learned before it can be advertised. [RFC4203] suggests using the TE Link Local LSA [RFC3630] to communicate the Local Interface ID to neighbors on the link. Though such a mechanism works, it has some drawbacks.
从广告路由器的角度来看，本地接口ID是一个已知值。但是，需要先了解远程接口ID，然后才能公布它。[RFC4203]建议使用TE链路本地LSA[RFC3630]将本地接口ID传达给链路上的邻居。虽然这种机制有效，但也有一些缺点。
This document proposes an extension to OSPF link-local signaling (LLS) [RFC5613] to advertise the Local Interface ID.
本文件建议对OSPF链路本地信令（LLS）[RFC5613]进行扩展，以公布本地接口ID。
Usage of the Link Local TE Opaque LSA to propagate the Local Interface ID to the neighbors on the link is described in [RFC4203]. This mechanism has the following problems:
[RFC4203]中描述了使用链路本地LSA将本地接口ID传播到链路上的邻居。该机制存在以下问题：
o LSAs can only be flooded over an existing adjacency that is in Exchange state or greater. The adjacency state machine progresses independently on each side of the adjacency and, as such, may reach the Full state on one side before the Link Local TE Opaque LSA arrives. The consequence of this is that the link can be initially advertised without the Remote Interface ID. Later, when the Link Local TE Opaque LSA arrives, the link must be advertised again but this time with the valid Remote Interface ID. Implementations may choose to wait before advertising the link, but there is no guarantee that the neighbor will ever advertise the Link Local TE Opaque LSA with the Interface ID. In summary, the existing mechanism does not guarantee that the Remote Interface ID is known at the time the link is advertised.
o LSA只能淹没在处于交换状态或更高状态的现有邻接上。邻接状态机在邻接的每一侧上独立地进行，因此，可以在链路本地LSA到达之前在一侧上达到完全状态。这样做的结果是，最初可以在没有远程接口ID的情况下播发链路。稍后，当链路本地LSA到达时，必须再次播发链路，但这次必须使用有效的远程接口ID。实现可以选择在播发链路之前等待，但不能保证邻居会用接口ID公布链路本地LSA。总之，现有机制不能保证在公布链路时知道远程接口ID。
o The Link Local TE Opaque LSA is defined for MPLS Traffic Engineering, but the knowledge of the Remote Interface ID is useful also for cases where MPLS TE is not used. One example is the mentioned lack of a valid 2-way connectivity check for parallel point-to-point links between OSPF routers.
o 链路本地TE不透明LSA是为MPLS流量工程定义的，但远程接口ID的知识对于不使用MPLS TE的情况也很有用。一个例子是所提到的OSPF路由器之间的并行点到点链路缺乏有效的双向连接检查。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
To address the problems described earlier and to allow the Interface ID exchange to be part of the neighbor discovery process, we propose to extend OSPF link-local signaling to advertise the Local Interface ID in OSPF Hello and Database Description (DD) packets.
为了解决前面描述的问题并允许接口ID交换成为邻居发现过程的一部分，我们建议扩展OSPF链路本地信令以在OSPF Hello和数据库描述（DD）数据包中公布本地接口ID。
The Local Interface ID TLV is an LLS TLV. It has the following format:
本地接口ID TLV是LLS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18
类型：18
Length: 4 octets
长度：4个八位字节
Local Interface ID: The value of the Local Interface ID.
本地接口ID：本地接口ID的值。
Local Interface ID TLV signaling using LLS is applicable to all OSPF interface types other than virtual links.
使用LLS的本地接口ID TLV信令适用于除虚拟链路以外的所有OSPF接口类型。
If the Local Interface ID signaling via the Link Local TE Opaque LSA is supported in addition to the new LLS mechanism, implementations that support Local Interface ID signaling using LLS MUST prefer the Local Interface ID value received through LLS over the value received through the Link Local TE Opaque LSA if both are received from the same OSPF router.
如果除了新的LLS机制外，还支持通过链路本地TE不透明LSA的本地接口ID信令，支持使用LLS的本地接口ID信令的实现必须优先选择通过LLS接收的本地接口ID值，而不是通过链路本地LSA接收的值（如果两者都是从同一OSPF路由器接收的）。
Implementations that support Local Interface ID signaling via the Link Local TE Opaque LSA MAY continue to do so to ensure backward compatibility. If they also support Local Interface ID signaling using LLS as described in the document, they MUST signal the same Local Interface ID via both mechanisms.
通过链路本地LSA支持本地接口ID信令的实现可以继续这样做以确保向后兼容性。如果它们还支持使用文件中描述的LLS发送本地接口ID信号，则它们必须通过两种机制发送相同的本地接口ID信号。
During the rare conditions in which the Local Interface ID changes, a timing interval may exist where the received values of the Local Interface ID advertised through LLS and the Link Local TE Opaque LSA may differ. Such a situation is temporary, and received values via both mechanisms should become equal as soon as the next Hello and/or Link Local TE Opaque LSA is regenerated by the originator.
在本地接口ID改变的罕见条件期间，可能存在定时间隔，其中通过LLS播发的本地接口ID的接收值和链路本地LSA可能不同。这种情况是暂时的，一旦发起人重新生成下一个Hello和/或Link-Local-TE-Opaque-LSA，通过这两种机制接收到的值就应该相等。
IANA has allocated the following code point in the "Link Local Signalling TLV Identifiers (LLS Types)" subregistry of the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/ Value Identifiers (TLV)" registry.
IANA已在“开放最短路径优先（OSPF）链路本地信令（LLS）-类型/长度/值标识符（TLV）”注册表的“链路本地信令TLV标识符（LLS类型）”子区中分配了以下代码点。
18 - Local Interface ID TLV
18-本地接口ID TLV
The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the Local Interface ID TLV described in this document. The current usage of a neighbor's Local Interface ID is to disambiguate parallel links between OSPF routers. Hence, modification of the advertised Local Interface ID TLV may result in the wrong neighbor Interface ID being advertised in the OSPFv2 Extended Link Opaque LSA [RFC7684] and could prevent the link from being used. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block.
“OSPF链路本地信令”[RFC5613]的安全注意事项也适用于本文档中描述的本地接口ID TLV。当前使用邻居的本地接口ID是为了消除OSPF路由器之间并行链路的歧义。因此，修改播发的本地接口ID TLV可能导致在OSPFv2扩展链路不透明LSA[RFC7684]中播发错误的邻居接口ID，并且可能阻止链路被使用。如果在OSPF路由域[RFC5709][RFC7474]中使用身份验证，则还应使用加密身份验证TLV[RFC5613]来保护LLS块的内容。
Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a hard router or OSPF process failure. The reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate-limited to prevent denial-of-service (DoS) attacks.
接收格式错误的LLS本地接口ID TLV不得导致硬路由器或OSPF进程故障。应记录收到格式错误的LLS TLV或子TLV的情况，但必须限制此类记录的速率，以防止拒绝服务（DoS）攻击。
The Interface ID is assigned by the advertising OSPF router as a locally unique identifier and need not be unique in any broader context; it is not expected to contain any information about the device owner or traffic transiting the device, so there are no privacy concerns associated with its advertisement.
接口ID由广告OSPF路由器分配为本地唯一标识符，并且在任何更广泛的上下文中不需要是唯一的；它不应包含任何有关设备所有者或设备传输流量的信息，因此其广告不存在隐私问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<https://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, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<https://www.rfc-editor.org/info/rfc4203>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, <https://www.rfc-editor.org/info/rfc5613>.
[RFC5613]Zinin，A.，Roy，A.，Nguyen，L.，Friedman，B.，和D.Yeung，“OSPF链路本地信令”，RFC 5613，DOI 10.17487/RFC5613，2009年8月<https://www.rfc-editor.org/info/rfc5613>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc7684>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8379] Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L. Jalil, "OSPF Graceful Link Shutdown", RFC 8379, DOI 10.17487/RFC8379, May 2018, <https://www.rfc-editor.org/info/rfc8379>.
[RFC8379]Hegde，S.，Sarkar，P.，Gredler，H.，Nanduri，M.，和L.Jalil，“OSPF优雅链路关闭”，RFC 8379，DOI 10.17487/RFC8379，2018年5月<https://www.rfc-editor.org/info/rfc8379>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <https://www.rfc-editor.org/info/rfc2863>.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 2863，DOI 10.17487/RFC2863，2000年6月<https://www.rfc-editor.org/info/rfc2863>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5709]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 5709，DOI 10.17487/RFC5709，2009年10月<https://www.rfc-editor.org/info/rfc5709>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.
[RFC7474]Bhatia，M.，Hartman，S.，Zhang，D.，和A.Lindem，Ed.，“使用手动密钥管理时OSPFv2的安全扩展”，RFC 7474，DOI 10.17487/RFC7474，2015年4月<https://www.rfc-editor.org/info/rfc7474>.
Acknowledgments
致谢
Thanks to Tony Przygienda for his extensive review and useful comments.
感谢Tony Przygienda的广泛评论和有用的评论。
Authors' Addresses
作者地址
Peter Psenak (editor) Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 Bratislava 821 09 Slovakia
Peter Psenak（编辑）思科系统公司阿波罗商业中心Mlynske nivy 43布拉迪斯拉发821 09斯洛伐克
Email: ppsenak@cisco.com
Email: ppsenak@cisco.com
Ketan Talaulikar Cisco Systems, Inc. S.No. 154/6, Phase I, Hinjawadi Pune, Maharashtra 411 057 India
Ketan Talaulikar思科系统公司，编号。印度马哈拉施特拉邦欣贾瓦迪浦那一期154/6，邮编：411057
Email: ketant@cisco.com
Email: ketant@cisco.com
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium
Wim Henderickx诺基亚哥白尼50安特卫普2018比利时
Email: wim.henderickx@nokia.com
Email: wim.henderickx@nokia.com
Padma Pillay-Esnault Huawei USA 2330 Central Expressway Santa Clara, CA 95050 United States of America
美国加利福尼亚州圣克拉拉市中心高速公路2330号帕德玛·皮莱·埃斯纳尔特华为美国95050
Email: padma@huawei.com
Email: padma@huawei.com