summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5130.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5130.txt')
-rw-r--r--doc/rfc/rfc5130.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5130.txt b/doc/rfc/rfc5130.txt
new file mode 100644
index 0000000..12dff6f
--- /dev/null
+++ b/doc/rfc/rfc5130.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+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
+
+
+
+
+Previdi, et al. Standards Track [Page 1]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+1. Introduction
+
+ 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.
+
+ 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].
+
+ 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.
+
+2. Conventions Used in This Document
+
+ 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].
+
+3. Sub-TLV Additions
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Previdi, et al. Standards Track [Page 2]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+3.1. 32-bit Administrative Tag Sub-TLV 1
+
+ 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:
+
+ o 1 octet of type (value: 1)
+
+ o 1 octet of length (value: multiple of 4)
+
+ o one or more instances of 4 octets of administrative tag
+
+ 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".
+
+3.2. 64-bit Administrative Tag Sub-TLV 2
+
+ 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:
+
+ o 1 octet of type (value: 2)
+
+ o 1 octet of length (value: multiple of 8)
+
+ o one or more instances of 8 octets of administrative tag
+
+ 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".
+
+4. Ordering of Tags
+
+ 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
+
+
+
+
+
+Previdi, et al. Standards Track [Page 3]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+ 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.
+
+5. Compliance
+
+ 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.
+
+ 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.
+
+ 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.
+
+6. Operations
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Previdi, et al. Standards Track [Page 4]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+ R2--------R3--------R4
+ L2 / \
+ - - - /- - - - - - - - - - - - - -
+ L1 / \
+ R1----1.1.1.0/24 (A) R5
+ |
+ |
+ 1.1.2.0/24 (B)
+
+ Figure 1: Example of usage
+
+ 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".
+
+ 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.
+
+ 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.
+
+7. Security Considerations
+
+ 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.
+
+8. IANA Considerations
+
+ 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.
+
+9. Manageability Considerations
+
+ 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.
+
+
+
+
+Previdi, et al. Standards Track [Page 5]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+10. Acknowledgements
+
+ 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.
+
+11. Contributors
+
+ Brad Neal contributed portions of this document.
+
+12. References
+
+12.1. Normative References
+
+ [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.
+
+ [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+ dual environments", RFC 1195, December 1990.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+12.2. Informative References
+
+ [ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress,
+ October 2007.
+
+ [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
+ Distribution with Two-Level IS-IS", RFC 2966,
+ October 2000.
+
+ [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
+ System (IS-IS) Extensions for Traffic Engineering (TE)",
+ RFC 3784, June 2004.
+
+ [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
+ Topology (MT) Routing in IS-IS", RFC 5120,
+ February 2008.
+
+
+
+
+
+
+
+Previdi, et al. Standards Track [Page 6]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+Authors' Addresses
+
+ Stefano Previdi
+ Cisco Systems
+ Via Del Serafico, 200
+ 00142 Rome,
+ Italy
+
+ EMail: sprevidi@cisco.com
+
+
+ Mike Shand (editor)
+ Cisco Systems
+ 250, Longwater Avenue.
+ Reading, Berks RG2 6GB
+ UK
+
+ Phone: +44 208 824 8690
+ EMail: mshand@cisco.com
+
+
+ Christian Martin
+ iPath Services
+
+ EMail: chris@ipath.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Previdi, et al. Standards Track [Page 7]
+
+RFC 5130 IS-IS Admin Tags February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Previdi, et al. Standards Track [Page 8]
+