Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 7896 Huawei Technologies
Updates: 5440 June 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 7896 Huawei Technologies
Updates: 5440 June 2016
Category: Standards Track
ISSN: 2070-1721
Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)
更新路径计算元素通信协议（PCEP）中的包含路由对象（IRO）规范
Abstract
摘要
The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.
路径计算元素通信协议（PCEP）支持路径计算客户端（PCC）和PCE之间或两个PCE之间的通信。RFC 5440定义包含路由对象（IRO），以指定要在计算路径中遍历的网络元素。规范未指定IRO是否包含有序或无序的子对象列表。在最近的讨论中，确定有必要定义标准表示法以确保互操作性。还有人指出，处理IRO子对象的属性L位有一个好处。
This document updates RFC 5440 regarding the IRO specification.
本文件更新了关于IRO规范的RFC 5440。
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/rfc7896.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7896.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Update in the IRO Specification . . . . . . . . . . . . . . . 3
2.1. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . 3
3. Operational Considerations . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Update in the IRO Specification . . . . . . . . . . . . . . . 3
2.1. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . 3
3. Operational Considerations . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. [RFC5440] defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO is an ordered or unordered list of subobjects. In addition, it defines the L bit as having no meaning within an IRO.
路径计算元素通信协议（PCEP）支持路径计算客户端（PCC）和PCE之间或两个PCE之间的通信。[RFC5440]定义包含路由对象（IRO），以指定要在计算路径中遍历的网络元素。规范没有指定IRO是有序的还是无序的子对象列表。此外，它将L位定义为在IRO中没有意义。
[RFC5441] describes the use of an IRO to indicate the sequence of domains to be traversed during inter-domain path computation.
[RFC5441]描述了使用IRO来指示域间路径计算期间要遍历的域序列。
During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability.
在最近的讨论中，确定有必要定义标准表示法以确保互操作性。
This document updates the IRO specifications in Section 7.12 of [RFC5440].
本文件更新了[RFC5440]第7.12节中的IRO规范。
Section 7.12 of [RFC5440] describes the IRO as an optional object used to specify a set of network elements to be traversed in the computed path. It states that the L bit in the subobject has no meaning within an IRO. It does not mention if the IRO contains an ordered or unordered list of subobjects.
[RFC5440]第7.12节将IRO描述为可选对象，用于指定在计算路径中要遍历的一组网络元素。它表示子对象中的L位在IRO中没有意义。它没有提到IRO是否包含有序或无序的子对象列表。
The IRO specification is updated to remove the last line in the Section 7.12 of [RFC5440], which states:
更新了IRO规范，删除了[RFC5440]第7.12节中的最后一行，其中规定：
"The L bit of such sub-object has no meaning within an IRO."
“该子对象的L位在IRO中没有意义。”
Further, Section 7.12 of [RFC5440] is updated to add the following two statements at the end of the first paragraph.
此外，更新了[RFC5440]第7.12节，在第一段末尾添加了以下两个语句。
- The content of an IRO is an ordered list of subobjects representing a series of abstract nodes (refer to Section 4.3.2 of [RFC3209]).
- IRO的内容是表示一系列抽象节点的子对象的有序列表（参见[RFC3209]第4.3.2节）。
- The L bit of an IRO subobject is set based on the loose or strict hop property of the subobject; it is set if the subobject represents a loose hop. If the bit is not set, the subobject represents a strict hop. The interpretation of the L bit is as per Section 4.3.3.1 of [RFC3209].
- IRO子对象的L位是基于该子对象的松散或严格跃点特性设置的；如果子对象表示松散跃点，则会设置该值。如果未设置位，则子对象表示严格的跃点。L钻头的解释符合[RFC3209]第4.3.3.1节的要求。
Because of the lack of clarity in [RFC5440], it is possible to encounter implementations that always interpret the IRO subobjects as loose. When these implementations interwork with an implementation conforming to this document, the following impact might be seen:
由于[RFC5440]中缺乏明确性，可能会遇到总是将IRO子对象解释为松散的实现。当这些实施与符合本文件要求的实施相互配合时，可能会产生以下影响：
o If a non-conforming (to this document) PCC sends an IRO to a conforming (to this document) PCE, then the PCE may unexpectedly fail to find a path (since the PCC may think of the IRO subobjects as loose hops, but the PCE interprets them as strict hops).
o 如果不符合（本文件）的PCC向符合（本文件）的PCE发送IRO，则PCE可能会意外地找不到路径（因为PCC可能认为IRO子对象是松散的跃点，但PCE将其解释为严格的跃点）。
o If a conforming PCC sends an IRO containing strict hops to a non-conforming PCE, then the PCE may erroneously return a path that does not comply with the requested strict hops (since the PCE interprets them all as loose hops). The PCC may check the returned path and find the issue, or it may end up using an incorrect path.
o 如果一致性PCC向不一致性PCE发送包含严格跃点的IRO，则PCE可能会错误地返回不符合所请求的严格跃点的路径（因为PCE将它们全部解释为松散跃点）。PCC可能会检查返回的路径并找到问题，也可能最终使用不正确的路径。
This update in the IRO specification does not introduce any new security considerations, apart from those mentioned in [RFC5440]. Clarification in the supported IRO ordering or Loose hop bit handling will not have any negative security impact.
除了[RFC5440]中提到的安全注意事项外，IRO规范中的此更新没有引入任何新的安全注意事项。支持的IRO排序或松散跃点位处理中的澄清不会产生任何负面安全影响。
It is worth noting that PCEP operates over TCP. An analysis of the security issues for routing protocols that use TCP (including PCEP) is provided in [RFC6952].
值得注意的是，PCEP通过TCP进行操作。[RFC6952]对使用TCP（包括PCEP）的路由协议的安全问题进行了分析。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 5441，DOI 10.17487/RFC5441，2009年4月<http://www.rfc-editor.org/info/rfc5441>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，DOI 10.17487/RFC6952，2013年5月<http://www.rfc-editor.org/info/rfc6952>.
Acknowledgments
致谢
A special thanks to the PCE chairs for guidance regarding this work.
特别感谢PCE主席对这项工作的指导。
Thanks to Francesco Fondelli for his suggestions in clarifying the L bit usage.
感谢Francesco Fondelli在澄清L位用法方面提出的建议。
Thanks to Adrian Farrel for his review and comments.
感谢阿德里安·法雷尔的评论和评论。
Thanks to Jonathan Hardwick for shepherding the document and providing text in Section 3.
感谢Jonathan Hardwick指导本文件并在第3节中提供文本。
Thanks to Deborah Brungard for her comments and being the responsible AD.
感谢Deborah Brungard的评论，她是一个负责任的广告人。
Thanks to Peter Yee for the Gen-ART review.
感谢Peter Yee的Gen艺术评论。
Thanks to Alvaro Retana for comments during the IESG review.
感谢Alvaro Retana在IESG审查期间的评论。
Author's Address
作者地址
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦班加罗尔Whitefield Bangalore Dhruv Dhody华为技术分部，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com