[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05                                             
Network Working Group                                   Christian Martin
INTERNET DRAFT                             Verzion Global Networks, Inc.
                                                               Brad Neal
July 2001                                       Broadwing Communications



     A Policy Control Mechanism is IS-IS Using Administrative Tags
           <draft-martin-neal-policy-isis-admin-tags-00.txt>


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 that adds
  to its operational capabilities, and that allows for easier management
  of 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].

  This document enhances the IS-IS protocol by augmenting the
  information that a Intermediate System (IS or router) can place in
  Link State Protocol Data Units (LSPs) as specified in [2].  Operators
  who must control the distribution of IP prefix information throughout
  a multilevel, large scale topology will find this useful.

3. Specification of Requirements




Martin & Neal                                                   [Page 1]


INTERNET DRAFT                                                July 2001


  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 130 in [2],
  with additional information carried in TLV 135 as specified in [3]. In
  particular, the extended IP Reachibilty TLV (135) allows 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.

  As of this writing no sub-TLVs have been defined. This draft, however,
  proposes a sub-TLV that may be used to carry administrative
  information about an IP prefix.

5. Sub-TLV Additions

  This draft proposes a new "Administrative Tag" sub-TLV to be added to
  TLV 135: a 32 bit unsigned integer that may be associated with an IP
  prefix. This tag may, among other things, be used to control
  redistribution among areas, routing protocols, or multiple instances
  of IS-IS running on the same router.

  The methods by which the feature is employed are beyond the scope of
  this document and are left to the implementer and/or operator.

  The encoding of the sub-TLV is discussed in the following subsection.

5.1. Administrative Tag Sub-TLV [TBA]

  This sub-TLV [TBA] shall be used to associate an integer value with an
  IP prefix such that it may be used in routing policy to control the
  distribution of routing information within an IS-IS domain.  The
  Administrative Tag shall be encoded as a 4 octet unsigned integer.

  See the "IANA Considerations" section for additional information.

6. A compliant ISIS implementation...

  MUST be able to assign a policy tag 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




Martin & Neal                                                   [Page 2]


INTERNET DRAFT                                                July 2001


  SHOULD be able to rewrite or remove the policy-group of a received
  prefix according to its own policy.

  Unless stated otherwise, multiple occurrences of the tag are
  supported by multiple inclusions of the sub-TLV.


7. Operation

  An administrator associates a policy group identifier with some
  interesting property.  When IS-IS advertises reachability for some IP
  prefix that has that property, it adds the policy identefier 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   /                        \
                   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 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; 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.

8. 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 & Neal                                                   [Page 3]


INTERNET DRAFT                                                July 2001


9. IANA Considerations

  The value of the Administrative Tag sub-TLV [TBA] must be allocated.

10. Acknowledgments

  The author would like to thank Henk Smit for clarifying the best place
  to describe this new information, Tony Li for useful comments on this
  draft, and Danny McPherson for some much needed formatting assistance.

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

12. Authors' Address

  Christian Martin
  Verizon Global Networks, Inc.
  1880 Campus Commons Dr
  Reston, VA 20191
  USA
  Email: cmartin@gnilink.net
  Voice: 1 (703) 2954394
  Fax: 1 (703) 2954279

  Brad Neal
  Broadwing Communications
  1835 Kramer Lane - Suite 100
  Austin, TX 78758
  USA
  Email: bneal@broadwing.com
  Voice: 1 (512) 7421310
  Fax: 1 (512) 7421333



Martin & Neal                                                   [Page 4]

INTERNET DRAFT                                                July 2001