Internet Engineering Task Force Brad Neal Internet Draft (Broadwing Communications) Expiration Date: July 2001 January 2001 A Policy-Group Sub-TLV for IS-IS Extended IP Reachability Information draft-neal-policy-subtlv-isis-01.txt 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsolete 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 draft describes an extension to Integrated IS-IS, which can be used to pass additional information among routers within an IS-IS domain that can aid in policy administration. This extension is roughly similar in operation to the BGP communities attribute; in that it provides a mechanism to associate a routed prefix with some administrative group, such that an administrator may define a routing policy for that group. 3. Introduction It is sometimes necessary for a network administrator to control the distribution of reachability information in a routing domain according to some policy. In particular, an administrator may wish control which active routes are advertised to various neighbors, or which active routes are redistributed into other protocols. There are several syntaxes for routing-policy specification among vendors, but most consist of an ordered list of 'match' conditions and 'set' actions that is applied to a routing process. Most implementations allow a match condition to be a simple list of statically defined prefixes, or some attribute associated with a prefix in the context of the protocol through which it was learned (e.g., "match all area A routes, and redistribute into..."). In general, it is more preferable to match some transitive attribute of a prefix, rather than define a static list as a match condition. This is due to the administrative complexity of maintaining said list at every node that must apply that policy. Sometimes an administrator may wish to match a group of routes with some common logical property. For interdomain routing with BGP, [COMM] defines a protocol extension that is helpful in this regard; and has, in practical implementation, come to be of significant utility. 4. Policy-Group Sub-TLV There does not currently exist a mechanism in the IS-IS protocol specification [ISIS-IP], or in the proposed standard [ISIS-TE] that allows an us to arbitrarily identify an IP prefix as a member of an administratively defined group. In most current implementations; if an administrator wishes to match routes with some common property, that administrator must define a static list of routed prefixes as a match condition. We suggest the definition of an "Policy-Group" extension to the IS-IS Extended IP Reachability Information" TLV which will address this. An administrator may define an interesting property and associate it with a policy-group. A policy-group identifier is, in turn, associated with an IP prefix with that property and 'sticks' to the IP reachability information for that prefix as it is flooded throughout the routing domain. A complient ISIS implementation... - MUST be able to assign a policy group to any IP prefix, for which it generates an extended IP reachability information TLV, - MUST be able to assign more than one tag to a particular prefix, and.. - SHOULD be able to rewrite or remove the policy-group of a received prefix according to its own policy. The policy-tag(s) is/are a sub-TLV carried within the Extended IP reachability TLV, whose TLV type is 135[ISIS-TE]. A tag is represented as a 16-bit value, so the length portion of the sub-TLV will be 2 times the number of tags asscociated with the ip prefix. 5. Operation Consider the network in figure 1. We wish to "leak" L1 prefixes [LEAK] 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 / \ R1 R5----1.1.1.0/24 (A) | | 1.1.2.0/24 (B) Figure 1 We associate policy-group 100 with property A, and have R5 attach that value, in a sub-TLV, to the IP extended reachability information TLV for prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with policy-group 100, and leak to L1." The previous example is rather simplistic, and 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. 6. Security Considerations This documents raises no new security issues for IS-IS. 7. References [COMM] R. Chandra, P Traina, "BGP Communities Attribute", RFC 1997, August 1996 [ISIS-IP] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" RFC 1195, December 1990 [ISIS-TE] Tony Li, Henk Smit, "IS-IS extensions for Traffic Engineering", work in progress [LEAK] T. Li, T Przygienda, H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000 8. Author's Address Postal: Brad Neal Broadwing Communications 1835 Kramer Lane - Suite 100 Austin, Texas 78758 USA Email: bneal@broadwing.com Full Copyright Statement "Copyright (C) The Internet Society (March 2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.