Network Working Group Christian Martin INTERNET DRAFT Verizon Internet Services Expiration Date: January 2003 Brad Neal Broadwing Communications Stefano Previdi August 2002 Cisco Systems A Policy Control Mechanism is IS-IS Using Administrative Tags 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. 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. The IS- IS protocol is specified in [1], with extensions for supporting IPv4 specified in [2] and further enhancements for Traffic Engineering [4] in [3] and [6]. This document enhances the IS-IS protocol by extending the information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs) as specified in [2]. This Martin, Neal, Previdi Expires January 2003 [Page 1] INTERNET DRAFT draft-ietf-isis-admin-tags-00.txt August 2002 extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it is used in the currently defined TLVs. 3. Specification of Requirements 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 [RFC 2119]. 4. Introduction As defined in [2] and extended in [3], the IS-IS protocol may be used to distribute IP prefix reachibility information throughout an IS-IS domain. The IP prefix information is encoded as TLV type 128 and 130 in [2], with additional information carried in TLV 135 as specified in [3] and TLV 235 as defined in [6]. In particular, the extended IP Reachabilty 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 MultiTopology membership information [6]. As of this writing no sub-TLVs have been defined; however, this draft proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used to carry administrative information about an IP prefix. 5. Sub-TLV Additions This draft proposes 2 new "Administrative Tag" sub-TLVs to be added to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 bit unsigned integers that may be associated with an IP prefix. Example uses of these tags include controlling redistribution between levels and areas, different routing protocols, or multiple instances of IS-IS running on the same router, or carrying BGP standard or extended communites. 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 Martin, Neal, Previdi Expires January 2003 [Page 2] INTERNET DRAFT draft-ietf-isis-admin-tags-00.txt August 2002 subsections. 5.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 [3] and TLV 235 [6]. The Administrative Tag Sub-TLV has following structure: 1 octet of type (value: 1) 1 octet of length (value: multiple of 4) one or more instances of 4 octets of administrative tag An implementation may consider only one of the encoded tags, in which case the first encoded tag must be considered. A tag value of zero is reserved and should be treated as "no tag". 5.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 [3] and TLV 235 [6]. The 64-bit Administrative Tag Sub-TLV has following structure: 1 octet of type (value: 1) 1 octet of length (value: multiple of 8) one or more instances of 8 octets of administrative tag An implementation may consider only one of the encoded tags, in which case the first encoded tag must be considered. A tag value of zero is reserved and should be treated as "no tag". 6. 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 preceeds or succeeds tag B SHOULD not change the meaning of the tag set. However, an implementation MAY wish to preserve tag ordering such that an ordered set of tags has meaning to the local policy. Each IS that receives an LSP with TLV(s) 135 and/or 235, that have associated SubTLV(s) 1 and/or 2, MAY operate on the tag values as warranted by the implementation. If an implementation needs to Martin, Neal, Previdi Expires January 2003 [Page 3] INTERNET DRAFT draft-ietf-isis-admin-tags-00.txt August 2002 change tag values, for example, at an area boundary, then the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s) MAY change as dictated by the policy action. In the event that no change is required, the SubTLV(s) SHOULD be copied in order into the new LSP, such that ordering is preserved. 7. A compliant IS-IS implementation: MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or 235. MAY be able to assign more than one tag to any IP prefix in TLV(s) 135 and/or 235. MAY be able to rewrite or remove one or more tags associated with a prefix in TLV(s) 135 and/or 235 upon LSP generation at an area boundary. 8. Operation 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 domian. Consider the network in figure 1. We wish to "leak" L1 prefixes [5] 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. R2--------R3--------R4 L2 / \ - - - /- - - - - - - - - - - - - - L1 / \ R5----1.1.1.0/24 (A) R5 | | 1.1.2.0/24 (B) Figure 1 Martin, Neal, Previdi Expires January 2003 [Page 4] INTERNET DRAFT draft-ietf-isis-admin-tags-00.txt August 2002 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.1.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.1.0/24. However, if there are a large number of routers that need to apply some policy according to property A and large number of "A" prefixes, this mechanism can be quite helpful. 9. 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. 10. IANA Considerations The authors have chosen "1" as the typecode of the 32-bit Administrative Tag sub-TLV and "2" as the typecode of the 64-bt Administrative Tag SubTLV. These values must be allocated by IANA. 11. Acknowledgments 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 draft, Danny McPherson for some much needed formatting assistance, and Mike Shand for useful discussions on encoding structure of the sub-TLV. Martin, Neal, Previdi Expires January 2003 [Page 5] INTERNET DRAFT draft-ietf-isis-admin-tags-00.txt August 2002 12. References [1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", Internet Draft, "Work in Progress", September 2000. [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999. [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution with Two-Level IS-IS" RFC 2966, October 2000 [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 2002. 13. Authors' Address Christian Martin Verizon Internet Services 1880 Campus Commons Dr Reston, VA 20191 Email: cmartin@gnilink.net Brad Neal Broadwing Communications 1835 Kramer Lane - Suite 100 Austin, TX 78758 USA Email: bneal@broadwing.com Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium email: sprevidi@cisco.com Martin, Neal, Previdi Expires January 2003 [Page 6]