Network Working Group S. Previdi
Request for Comments: 5130 M. Shand, Ed.
Category: Standards Track Cisco Systems
C. Martin
iPath Services
February 2008
Network Working Group S. Previdi
Request for Comments: 5130 M. Shand, Ed.
Category: Standards Track Cisco Systems
C. Martin
iPath Services
February 2008
A Policy Control Mechanism in IS-IS Using Administrative Tags
IS-IS中使用管理标记的策略控制机制
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains.
本文档描述了IS-IS协议的扩展，以添加操作功能，使IS-IS域内的IP前缀分发易于管理和控制。本文档通过扩展中间系统（IS）路由器可以放置在链路状态协议（LSP）数据单元中的信息来增强IS-IS协议，以供策略使用。此扩展将为运营商提供一种机制来控制IP前缀在多层次IS-IS域中的分布。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 3
3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 3
4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 3
5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Manageability Considerations . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 3
3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 3
4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 3
5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Manageability Considerations . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . . 6
As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol [ISO10589] may be used to distribute IPv4 prefix reachability information throughout an IS-IS domain. In addition, thanks to extensions made in [RFC5120] and [ISIS-IPv6], IS-IS may be used to distribute IPv6 reachability information.
如[RFC1195]中定义并在[RFC3784]中扩展的，IS-IS协议[ISO10589]可用于在整个IS-IS域中分发IPv4前缀可达性信息。此外，由于[RFC5120]和[ISIS-IPv6]中的扩展，IS-IS可用于分发IPv6可达性信息。
The IPv4 prefix information is encoded as TLV type 128 and 130 in [RFC1195], with additional information carried in TLV 135 as specified in [RFC3784] and TLV 235 as defined in [RFC5120]. In particular, the extended IP Reachability TLV (TLV 135) contains support for a larger metric space, an up/down bit to indicate redistribution between different levels in the hierarchy, an IP prefix, and one or more sub-TLVs that can be used to carry specific information about the prefix. TLV 235 is a derivative of TLV 135, with the addition of Multi-Topology membership information [RFC5120]. The IPv6 prefix information is encoded as TLV 236 in [ISIS-IPv6], and TLV 237 in [RFC5120].
IPv4前缀信息在[RFC1195]中编码为TLV类型128和130，在[RFC3784]中规定的TLV 135中携带附加信息，在[RFC5120]中定义的TLV 235中携带附加信息。具体地，扩展IP可达性TLV（TLV 135）包含对更大度量空间的支持、用于指示层次结构中不同级别之间的重新分配的向上/向下位、IP前缀以及可用于携带关于前缀的特定信息的一个或多个子TLV。TLV 235是TLV 135的衍生产品，添加了多拓扑成员信息[RFC5120]。IPv6前缀信息在[ISIS-IPv6]中编码为TLV 236，在[RFC5120]中编码为TLV 237。
This document defines 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237 that may be used to carry administrative information about an IP prefix.
本文件为TLV 135、TLV 235、TLV 236和TLV 237定义了2个新的子TLV，可用于承载有关IP前缀的管理信息。
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 BCP 14, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
This document creates 2 new "Administrative Tag" sub-TLVs to be added to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or more 32- or 64-bit unsigned integers that may be associated with an IP prefix. Example uses of these tags include carrying BGP standard (or extended) communities and controlling redistribution between levels and areas, different routing protocols, or multiple instances of IS-IS running on the same router.
本文件创建了2个新的“管理标签”子TLV，以添加到TLV 135、TLV 235、TLV 236和TLV 237中。这些TLV指定一个或多个可能与IP前缀关联的32位或64位无符号整数。这些标签的示例用途包括承载BGP标准（或扩展）社区和控制级别和区域之间的重新分配、不同路由协议或在同一路由器上运行的IS-IS的多个实例。
The methods for which their use is employed is beyond the scope of this document and left to the implementer and/or operator.
其使用的方法超出了本文件的范围，由实施者和/或操作员决定。
The encoding of the sub-TLV(s) is discussed in the following subsections.
子TLV的编码将在以下小节中讨论。
The Administrative Tag SHALL be encoded as one or more 4-octet unsigned integers using Sub-TLV 1 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The Administrative Tag Sub-TLV has following structure:
应使用TLV 135[RFC3784]、TLV 235[RFC5120]、TLV 236[ISIS-IPv6]和TLV 237[RFC5120]中的子TLV 1将管理标签编码为一个或多个4八位无符号整数。管理标记子TLV具有以下结构：
o 1 octet of type (value: 1)
o 类型的1个八位字节（值：1）
o 1 octet of length (value: multiple of 4)
o 长度的1个八位字节（值：4的倍数）
o one or more instances of 4 octets of administrative tag
o 管理标记的4个八位字节的一个或多个实例
On receipt, an implementation MAY consider only one encoded tag, in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
在接收时，实现可能只考虑一个编码标签，在这种情况下，必须考虑第一编码标签，并且忽略任何附加标签。保留零标记值，应将其视为“无标记”。
The Administrative Tag SHALL be encoded as one or more 8-octet unsigned integers using Sub-TLV 2 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The 64-bit Administrative Tag Sub-TLV has following structure:
应使用TLV 135[RFC3784]、TLV 235[RFC5120]、TLV 236[ISIS-IPv6]和TLV 237[RFC5120]中的子TLV 2将管理标签编码为一个或多个8位无符号整数。64位管理标记子TLV具有以下结构：
o 1 octet of type (value: 2)
o 类型的1个八位字节（值：2）
o 1 octet of length (value: multiple of 8)
o 长度的1个八位字节（值：8的倍数）
o one or more instances of 8 octets of administrative tag
o 管理标记的8个八位字节的一个或多个实例
On receipt, an implementation MAY consider only one encoded tag; in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
在接收时，实现可以只考虑一个编码标签；在这种情况下，必须考虑第一个编码的标记，并忽略任何附加标记。保留零标记值，应将其视为“无标记”。
The semantics of the tag order are implementation-dependent. That is, there is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need be performed based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A precedes or succeeds tag B SHOULD not change the meaning of the tag set. However, when propagating TLVs that contain multiple tags between levels, an implementation SHOULD
标记顺序的语义依赖于实现。也就是说，对于指示需要基于标签的顺序执行特定操作或操作集的标签的顺序没有隐含意义。应将每个标记视为可在策略中用于执行策略操作的自治标识符。标记A是否在标记B之前或之后，不应改变标记集的含义。但是，当在级别之间传播包含多个标记的TLV时，应该使用一个实现
preserve the ordering such that the first tag remains the first tag, so that implementations that only recognize a single tag will have a consistent view across levels.
保留顺序，以便第一个标记仍然是第一个标记，以便仅识别单个标记的实现在各个级别上具有一致的视图。
Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 and/or 237, that have associated sub-TLV(s) 1 and/or 2, MAY operate on the tag values as warranted by the implementation. If an implementation needs to change tag values, for example, when propagating TLVs between levels at an area boundary, then the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP. At that point, the contents of the sub-TLV(s) MAY change as dictated by the policy action. In the event that no change is required, the sub-TLV(s) SHOULD be copied in order into the new LSP, such that ordering is preserved.
接收具有具有关联子TLV 1和/或2的TLV 135和/或235和/或236和/或237的LSP的每个IS可根据实现保证对标签值进行操作。如果实现需要更改标记值，例如，在区域边界的级别之间传播TLV时，则应将TLV复制到新生成的级别1或级别2 LSP。此时，子TLV的内容可能会根据政策行动的指示发生变化。如果不需要更改，则应将子TLV按顺序复制到新LSP中，以便保留顺序。
A compliant IS-IS implementation MUST be able to assign one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MUST be able to interpret a single tag present in the sub-TLV, or the first tag where there is more than one tag present in the sub-TLV.
兼容IS-IS实现必须能够将一个标记分配给以下任一TLV中的任何IP前缀：TLV 135、TLV 235、TLV 236、TLV 237。它必须能够解释子TLV中存在的单个标签，或者解释子TLV中存在多个标签的第一个标签。
A compliant IS-IS implementation MAY be able to assign more than one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MAY be able to interpret the second and subsequent tags where more than one tag is present in the sub-TLV.
兼容IS-IS实现可以将多个标签分配给以下任一TLV中的任何IP前缀：TLV 135、TLV 235、TLV 236、TLV 237。当子TLV中存在多个标签时，它可能能够解释第二个和后续标签。
When propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237.
当在级别之间传播TLV时，兼容IS-IS实现可以重写或移除与以下TLV中的任一TLV中的前缀相关联的一个或多个标记：TLV 135、TLV 235、TLV 236、TLV 237。
An administrator associates an Administrative Tag value with some interesting property. When IS-IS advertises reachability for some IP prefix that has that property, it adds the Administrative Tag to the IP reachability information TLV for that prefix, and the tag "sticks" to the prefix as it is flooded throughout the routing domain.
管理员将管理标记值与一些有趣的属性相关联。当IS-IS播发具有该属性的某个IP前缀的可访问性时，它会将管理标记添加到该前缀的IP可访问性信息TLV中，并且标记会“粘住”前缀，因为它在整个路由域中被淹没。
Consider the network in Figure 1. We wish to "leak" L1 prefixes [RFC2966] with some property, A, from L2 to the L1 router R1. Without policy groups, there is no way for R2 to know property A prefixes from property B prefixes.
考虑图1中的网络。我们希望将具有某些属性A的L1前缀[RFC2966]从L2“泄漏”到L1路由器R1。如果没有策略组，R2就无法从属性B前缀中了解属性A前缀。
R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
Figure 1: Example of usage
图1：使用示例
We associate Administrative Tag 100 with property A, and have R5 attach that value to the IP extended reachability information TLV for prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with Administrative Tag 100, and leak to L1".
我们将管理标签100与属性A关联，并让R5将该值附加到前缀1.1.2.0/24的IP扩展可达性信息TLV。R2有一个适当的策略“将前缀与管理标记100匹配，并泄漏到L1”。
The previous example is rather simplistic; it seems that it would be just as easy for R2 simply to match the prefix 1.1.2.0/24. However, if there are a large number of routers that need to apply some policy according to property A and a large number of "A" prefixes, this mechanism can be quite helpful.
前面的例子相当简单；似乎R2只需匹配前缀1.1.2.0/24也同样容易。但是，如果有大量路由器需要根据属性a应用某些策略，并且有大量“a”前缀，那么这种机制可能非常有用。
Implementations that support only a single tag and those that support multiple tags may coexist in the same IS-IS domain. An implementation supporting multiple tags SHOULD therefore assign any tag that is required to be interpreted by all systems as the first tag in any set of multiple tags.
仅支持单个标记和支持多个标记的实现可能共存于同一IS-IS域中。因此，支持多个标记的实现应该将所有系统需要解释的任何标记指定为任何多个标记集合中的第一个标记。
This document raises no new security issues for IS-IS, as any annotations to IP prefixes should not pass outside the administrative control of the network operator of the IS-IS domain. Such an allowance would violate the spirit of Interior Gateway Protocols in general and IS-IS in particular.
本文档不会对IS-IS提出新的安全问题，因为IP前缀的任何注释都不应超出IS-IS域的网络运营商的管理控制范围。这种允许将违反内部网关协议的精神，尤其是IS-IS。
IANA has assigned "1" as the type code of the 32-bit Administrative Tag Sub-TLV and "2" as the type code of the 64-bit Administrative Tag Sub-TLV.
IANA已指定“1”作为32位管理标签子TLV的类型代码，“2”作为64位管理标签子TLV的类型代码。
These extensions have been designed, developed, and deployed for many years and do not have any new impact on management and operation of the IS-IS protocol via this standardization process.
这些扩展经过多年的设计、开发和部署，并没有通过此标准化过程对IS-IS协议的管理和操作产生任何新的影响。
The authors would like to thank Henk Smit for clarifying the best place to describe this new information, Tony Li and Tony Przygienda for useful comments on this document, and Danny McPherson for some much needed formatting assistance.
作者要感谢Henk Smit澄清了描述此新信息的最佳位置，感谢Tony Li和Tony Przygienda对本文档的有用评论，感谢Danny McPherson提供了一些急需的格式帮助。
Brad Neal contributed portions of this document.
Brad Neal贡献了本文件的部分内容。
[ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002.
[ISO10589]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2007.
[ISIS-IPv6]Hopps，C.，“使用IS-IS路由IPv6”，正在进行的工作，2007年10月。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]Li，T.，Przygienda，T.，和H.Smit，“具有两级IS-IS的域范围前缀分布”，RFC 2966，2000年10月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", RFC 5120, February 2008.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS:IS-IS中的多拓扑（MT）路由”，RFC 5120，2008年2月。
Authors' Addresses
作者地址
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome, Italy
Stefano Previdi Cisco Systems Via Del Serafico，意大利罗马，200 00142
EMail: sprevidi@cisco.com
EMail: sprevidi@cisco.com
Mike Shand (editor) Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
Mike Shand（编辑）思科系统公司，朗沃特大道250号。雷丁，伯克斯RG2 6GB英国
Phone: +44 208 824 8690
EMail: mshand@cisco.com
Phone: +44 208 824 8690
EMail: mshand@cisco.com
Christian Martin iPath Services
Christian Martin iPath服务公司
EMail: chris@ipath.net
EMail: chris@ipath.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.