<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml">
<!ENTITY RFC3784 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3784.xml">
<!ENTITY RFC2702 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml">
<!ENTITY RFC2966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2966.xml">
<!ENTITY MT SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-wg-multi-topology.xml">
<!ENTITY IPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-ipv6.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-isis-admin-tags-04.txt" ipr="full3978"
     updates="">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="IS-IS Admin Tags">A Policy Control Mechanism in IS-IS Using
    Administrative Tags</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Via Del Serafico, 200</street>

          <city>00142 Rome</city>

          <region></region>

          <code></code>

          <country>Italy</country>
        </postal>

        <email>sprevidi@cisco.com</email>
      </address>
    </author>

    <author fullname="Mike Shand" initials="M." role="editor" surname="Shand">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>250, Longwater Avenue.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Reading</city>

          <region>Berks</region>

          <code>RG2 6GB</code>

          <country>UK</country>
        </postal>

        <phone>+44 208 824 8690</phone>

        <email>mshand@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Christian Martin" initials="C." surname="Martin">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street>1880 Campus Commons Dr</street>

          <city>Reston</city>

          <region></region>

          <code>VA 20191</code>

          <country>USA</country>
        </postal>

        <email>cmartin@verizon.com</email>
      </address>
    </author>

    <author fullname="Brad Neal" initials="B." surname="Neal">
      <organization>Broadwing Communications </organization>

      <address>
        <postal>
          <street>1835 Kramer Lane - Suite 100</street>

          <city>Austin</city>

          <region></region>

          <code>TX 78758 </code>

          <country>USA</country>
        </postal>

        <email>bneal@broadwing.com </email>
      </address>
    </author>

    <date year="2007" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Conventions used in this Document">
      <t>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, <xref
      target="RFC2119"></xref>.</t>

      <t></t>
    </section>

    <section title="Introduction">
      <t></t>

      <t>As defined in <xref target="RFC1195"></xref> and extended in <xref
      target="RFC3784"></xref>, the IS-IS protocol <xref
      target="ISO10589"></xref> may be used to distribute IPv4 prefix
      reachability information throughout an IS-IS domain. In addition, thanks
      to extensions made in <xref
      target="I-D.ietf-isis-wg-multi-topology"></xref> and <xref
      target="I-D.ietf-isis-ipv6"></xref>, IS-IS may be used to distribute
      IPv6 reachability information.</t>

      <t></t>

      <t>The IPv4 prefix information is encoded as TLV type 128 and 130 in
      <xref target="RFC1195"></xref>, with additional information carried in
      TLV 135 as specified in <xref target="RFC3784"></xref> and TLV 235 as
      defined in <xref target="I-D.ietf-isis-wg-multi-topology"></xref>. 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 <xref
      target="I-D.ietf-isis-wg-multi-topology"></xref>. The IPv6 prefix
      information is encoded as TLV 236 in <xref
      target="I-D.ietf-isis-ipv6"></xref> and TLV 237 in <xref
      target="I-D.ietf-isis-wg-multi-topology"></xref>.</t>

      <t></t>

      <t>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.</t>

      <t></t>
    </section>

    <section title="Sub-TLV Additions ">
      <t></t>

      <t>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.</t>

      <t>The methods for which their use is employed is beyond the scope of
      this document and left to the implementer and/or operator.</t>

      <t>The encoding of the sub-TLV(s) is discussed in the following
      subsections.</t>

      <section title="32-bit Administrative Tag Sub-TLV 1 ">
        <t></t>

        <t>The Administrative Tag SHALL be encoded as one or more 4 octet
        unsigned integers using Sub-TLV 1 in TLV-135 <xref
        target="RFC3784"></xref>, TLV 235 <xref
        target="I-D.ietf-isis-wg-multi-topology"></xref>, TLV 236 <xref
        target="I-D.ietf-isis-ipv6"></xref> and TLV 237 <xref
        target="I-D.ietf-isis-wg-multi-topology"></xref>. The Administrative
        Tag Sub-TLV has following structure:</t>

        <t><list style="symbols">
            <t>1 octet of type (value: 1)</t>

            <t>1 octet of length (value: multiple of 4)</t>

            <t>one or more instances of 4 octets of administrative tag</t>
          </list></t>

        <t></t>

        <t></t>

        <t>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".</t>
      </section>

      <section title="64-bit Administrative Tag Sub-TLV 2  ">
        <t></t>

        <t>The Administrative Tag SHALL be encoded as one or more 8 octet
        unsigned integers using Sub-TLV 2 in TLV-135 <xref
        target="RFC3784"></xref>, TLV 235 <xref
        target="I-D.ietf-isis-wg-multi-topology"></xref>, TLV 236 <xref
        target="I-D.ietf-isis-ipv6"></xref> and TLV 237 <xref
        target="I-D.ietf-isis-wg-multi-topology"></xref>. The 64-bit
        Administrative Tag Sub-TLV has following structure:</t>

        <t><list style="symbols">
            <t>1 octet of type (value: 2)</t>

            <t>1 octet of length (value: multiple of 8)</t>

            <t>one or more instances of 8 octets of administrative tag</t>
          </list></t>

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

        <t></t>
      </section>
    </section>

    <section title="Ordering of Tags  ">
      <t></t>

      <t>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.</t>

      <t>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.</t>

      <t></t>
    </section>

    <section title="Compliance">
      <t></t>

      <t>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</t>

      <t>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</t>

      <t>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.</t>
    </section>

    <section title="Operations  ">
      <t></t>

      <t>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.</t>

      <t></t>

      <t>Consider the network in <xref target="fig_example"></xref>. We wish
      to "leak" L1 prefixes <xref target="RFC2966"></xref> 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.</t>

      <t></t>

      <figure anchor="fig_example" title="Example of usage">
        <preamble></preamble>

        <artwork><![CDATA[                             R2--------R3--------R4 
                      L2     /                    \          
                      - - - /- - - - - - - - - - - - - - 
                      L1   /                        \               
                         R1----1.1.1.0/24 (A)       R5 
                                                     | 
                                                     | 
                                               1.1.2.0/24 (B) 
]]></artwork>

        <postamble></postamble>
      </figure>

      <t></t>

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

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Security Considerations">
      <t></t>

      <t>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</t>
    </section>

    <section title="IANA Considerations">
      <t></t>

      <t>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.</t>
    </section>

    <section title="Manageability Considerations">
      <t>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.</t>
    </section>

    <section title="Acknowledgements">
      <t></t>

      <t>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.</t>
    </section>

    <!-- -->
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <reference anchor="ISO10589">
        <front>
          <title>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)</title>

          <author>
            <organization abbrev="ISO">International Organization for
            Standardization</organization>
          </author>

          <date month="Nov" year="2002" />
        </front>

        <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition" />
      </reference>

      &RFC2119;

      &RFC1195;

 
    </references>

    <references title="Informative References">

     &RFC2966;

     &RFC3784;

     &MT;

     &IPv6;
    </references>
  </back>
</rfc>