TOC 
Network Working GroupS. Previdi
Internet-DraftM. Shand, Ed.
Intended status: Standards TrackCisco Systems
Expires: May 22, 2008C. Martin
 Verizon
 B. Neal
 Broadwing Communications
 November 19, 2007


A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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.

This Internet-Draft will expire on May 22, 2008.

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 adraft-ietf-isis-wg-multi-topology 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.



Table of Contents

1.  Conventions used in this Document
2.  Introduction
3.  Sub-TLV Additions
    3.1.  32-bit Administrative Tag Sub-TLV 1
    3.2.  64-bit Administrative Tag Sub-TLV 2
4.  Ordering of Tags
5.  Compliance
6.  Operations
7.  Security Considerations
8.  IANA Considerations
9.  Manageability Considerations
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Introduction

As defined in [RFC1195] (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.) and extended in [RFC3784] (Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE),” June 2004.), the IS-IS protocol [ISO10589] (International Organization for Standardization, “Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473),” Nov 2002.) may be used to distribute IPv4 prefix reachability information throughout an IS-IS domain. In addition, thanks to extensions made in [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.) and [I‑D.ietf‑isis‑ipv6] (Hopps, C., “Routing IPv6 with IS-IS,” October 2007.), IS-IS may be used to distribute IPv6 reachability information.

The IPv4 prefix information is encoded as TLV type 128 and 130 in [RFC1195] (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.), with additional information carried in TLV 135 as specified in [RFC3784] (Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE),” June 2004.) and TLV 235 as defined in [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.). 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 [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.). The IPv6 prefix information is encoded as TLV 236 in [I‑D.ietf‑isis‑ipv6] (Hopps, C., “Routing IPv6 with IS-IS,” October 2007.) and TLV 237 in [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.).

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.



 TOC 

3.  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 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.



 TOC 

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] (Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE),” June 2004.), TLV 235 [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.), TLV 236 [I‑D.ietf‑isis‑ipv6] (Hopps, C., “Routing IPv6 with IS-IS,” October 2007.) and TLV 237 [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.). The Administrative Tag Sub-TLV has following structure:

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".



 TOC 

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] (Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE),” June 2004.), TLV 235 [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.), TLV 236 [I‑D.ietf‑isis‑ipv6] (Hopps, C., “Routing IPv6 with IS-IS,” October 2007.) and TLV 237 [I‑D.ietf‑isis‑wg‑multi‑topology] (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” November 2007.). The 64-bit Administrative Tag Sub-TLV has following structure:

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".



 TOC 

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 containing multiple tags between levels, an implementation SHOULD preserve the ordering such that the first tag remains the first tag, so that implementations which only recognise 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 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, 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 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.



 TOC 

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

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 when propagating TLVs between levels.



 TOC 

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 (Example of usage). We wish to "leak" L1 prefixes [RFC2966] (Li, T., Przygienda, T., and H. Smit, “Domain-wide Prefix Distribution with Two-Level IS-IS,” October 2000.) 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: 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 large number of "A" prefixes, this mechanism can be quite helpful.

Implementations which support only a single tag and those which support multiple tags may co-exist in the same IS-IS domain. An implementatation supporting multiple tags SHOULD therefor assign any tag which is required to be interpretted by all systems as the first tag in any set of multiple tags.



 TOC 

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



 TOC 

8.  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.



 TOC 

9.  Manageability Considerations

These extensions which have been designed, developed and deployed for many years do not have any new impact on management and operation of the ISIS protocol via this standardization process.



 TOC 

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 draft, Danny McPherson for some much needed formatting assistance.



 TOC 

11.  References



 TOC 

11.1. Normative References

[ISO10589] International Organization for Standardization, “Intermediate system to Intermediate system intra-domain routeing 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 (TXT, PS).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

11.2. Informative References

[I-D.ietf-isis-ipv6] Hopps, C., “Routing IPv6 with IS-IS,” draft-ietf-isis-ipv6-07 (work in progress), October 2007 (TXT).
[I-D.ietf-isis-wg-multi-topology] Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” draft-ietf-isis-wg-multi-topology-12 (work in progress), November 2007 (TXT).
[RFC2966] Li, T., Przygienda, T., and H. Smit, “Domain-wide Prefix Distribution with Two-Level IS-IS,” RFC 2966, October 2000 (TXT).
[RFC3784] Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE),” RFC 3784, June 2004 (TXT).


 TOC 

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
  Verizon
  1880 Campus Commons Dr
  Reston, VA 20191
  USA
Email:  cmartin@verizon.com
  
  Brad Neal
  Broadwing Communications
  1835 Kramer Lane - Suite 100
  Austin, TX 78758
  USA
Email:  bneal@broadwing.com


 TOC 

Full Copyright Statement

Intellectual Property