IS-IS Working Group                                    Christian Martin 
                                                                       Verizon 
      IETF Internet Draft                                     Stefano Previdi 
                                                                 Cisco Systems 
                                                                    Brad Neal 
                                                      Broadwing Communications 
                                                       
                                                       
                                                                               
                                                                               
      Expires: August 2005                                       February 2005 
       
       
              A Policy Control Mechanism in IS-IS Using Administrative Tags 
          
          
                      <draft-ietf-isis-admin-tags-03.txt> 
       
       
      Status of this Memo 
          
         By submitting this Internet-Draft, I certify that any applicable 
         patent or IPR claims of which I am aware have been disclosed, and any 
         of which I become aware will be disclosed, in accordance with RFC 
         3668. 
       
         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 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. 
       
       
       
       
       
       
       
       
       
       
      Martin, Previdi, Neal.                                          [Page 1] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

          
      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 a Intermediate System (IS) [router] can place in Link State 
         Protocol Data Units (LSPs) for policy use. This 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. 
       
       
      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 RFC-2119. 
       
          
       
      1. Introduction 
          

         As defined in [2] and extended in [3], the IS-IS protocol may be used 
         to distribute IPv4 prefix reachability information throughout an IS-
         IS domain. In addition, thanks to extensions made in [6] and [7], IS-
         IS may be used to distribute IPv6 reachability information.  
          
          
         The IPv4 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 
         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 [6]. The IPv6 prefix information is encoded as 
         TLV 236 in [7] and TLV 237 in [6]. 
          
          
         As of this writing no sub-TLVs have been defined; however, this draft 
         proposes 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. 
          
          
           
          
       
      Martin, Previdi, Neal.                                        [Page 2] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

          
      2. Sub-TLV Additions 
          

         This draft proposes 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 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 communities. 
          
          
         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. 
          
          
         2.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], TLV 235 [6], TLV 
         236 [7] and TLV 237 [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". 
       
       
         2.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], TLV 235 [6], TLV 
         236 [7] and TLV 237 [6]. The 64-bit Administrative Tag Sub-TLV has 
         following structure: 
          
          
                 1 octet of type (value: 2) 
                 1 octet of length (value: multiple of 8) 
                 one or more instances of 8 octets of administrative tag 
          
          

       
      Martin, Previdi, Neal.                                        [Page 3] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

         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". 
          
          
       
      3. 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, 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 and/or 236 
         and/or 237, 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 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. 
          
           
       
      4. 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. 
          
          
         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. 
          
          
         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. 
          
       
      5. Operations 
          

         An administrator associates an Administrative Tag value with some 
         interesting property.  When IS-IS advertises reachability for some IP 
       
      Martin, Previdi, Neal.                                        [Page 4] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

         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 [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   /                        \               
                         R1----1.1.1.0/24 (A)       R5 
                                                     | 
                                                     | 
                                               1.1.2.0/24 (B) 
          
          
          
                                    Figure 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." 
          
          
         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 large number of "A" prefixes, this 
         mechanism can be quite helpful. 
          
          
      6. 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 
          
          
          
          

       
      Martin, Previdi, Neal.                                        [Page 5] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

      7. IANA Considerations 
         
 
         The authors have chosen "1" as the type code of the 32-bits 
         Administrative Tag Sub-TLV and "2" as the type code of the 64-bits 
         Administrative Tag Sub-TLV. These values must be allocated by IANA. 
          
       
          
      8. Intellectual Property Statement 
         
 
         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..  
          
         8.1. IPR Disclosure Acknowledgement 
             

         By submitting this Internet-Draft, I certify that any applicable 
         patent or other IPR claims of which I am aware have been disclosed, 
         and any of which I become aware will be disclosed, in accordance with 
         RFC 3668. 
          
          
          
      9. 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, Previdi, Neal.                                        [Page 6] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

          
      10. References 
       

         10.1. Normative references 
       

         [RFC] Bradner, S., "Key words for use in RFCs to indicate 
         requirements levels", RFC 2119, March 1997. 
          
         [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 
         RFC 3667, February 2004. 
          
         [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 
         Technology", BCP 79, RFC 3668, February 2004. 
       
         [1] "Intermediate System to Intermediate System Intra-Domain Routing 
         Exchange Protocol " ISO 10589. 
          
         [2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 
         environments", RFC 1195, December 1990.  
       
         [3] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 
         3784, June 2004. 
          
         [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 
          
         10.2. Informative References 
          

         [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. 
       
         [7] Hopps, C., "Routing IPv6 with IS-IS", draft-ietf-isis-ipv6-
         05.txt, January 2003 
       
       
       
       
       
       
      11. Editors' Address  
           

          Christian Martin 
          Verizon 
          1880 Campus Commons Dr 
          Reston, VA 20191 
          Email: cmartin@verizon.com 
          
       
      Martin, Previdi, Neal.                                        [Page 7] 
         

       
      Internet Draft    draft-ietf-isis-admin-tags-03.txt      February 2005 

          
          Stefano Previdi 
          Cisco Systems, Inc. 
          Via Del Serafico, 200 
          00142 Roma - Italy 
          email: sprevidi@cisco.com 
          
          
          Brad Neal 
          Broadwing Communications 
          1835 Kramer Lane - Suite 100 
          Austin, TX 78758 
          USA 
          Email: bneal@broadwing.com 
           
      Full Copyright Statement 
       
      Copyright (C) The Internet Society (2005).  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 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. 
          
          











       
      Martin, Previdi, Neal.                                        [Page 8]