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

]>
<?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="info" docName="draft-li-hierarchical-isis-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    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="Hierarchical IS-IS">
     Hierarchical IS-IS
   </title>

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

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

   <author fullname="Tony Li" initials="T." 
           surname="Li">
     <organization>Arista Networks</organization>

     <address>
       <postal>
         <street>5453 Great America Parkway</street>

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

         <city>Santa Clara</city>

         <region>California</region>

         <code>95054</code>

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

       <phone></phone>

       <email>tony.li@tony.li</email>

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

   <date year="2018" />

   <!-- 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 -->

   <area>Routing</area>

   <workgroup>Internet Engineering Task Force</workgroup>

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

   <keyword>IS-IS multi-level hierarchical link-state routing</keyword>

   <!-- 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>
       The IS-IS routing protocol was originally defined with a two
       level hierarchical structure. This was adequate for the
       networks at the time. As we continue to expand the scale of our
       networks, it is apparent that additional hierarchy would be a
       welcome degree of flexibility in network design.
     </t>
     <t>
       This document defines IS-IS Levels 3 through 8.
     </t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
     <t>
       The IS-IS routing protocol <xref target="ISO10589">IS-IS</xref>
       currently supports a two level hierarchy of abstraction. The
       fundamental unit of abstraction is the 'area', which is a
       (hopefully) connected set of systems running IS-IS at the same
       level. Level 1, the lowest level, is abstracted by routers that
       participate in both Level 1 and Level 2.
     </t>
     <t>
       Practical considerations, such as the size of an area's link
       state database, cause network designers to restrict the number
       of routers in any given area. Concurrently, the dominance of
       scale-out architectures based around small routers has created
       a situation where the scalability limits of the protocol are
       going to become critical in the foreseeable future.
     </t>
     <t>
       The goal of this document is to enable additional hierarchy
       within IS-IS by creating additional hierarchy.  Each additional
       level of hierarchy has a multiplicative effect on scale, so the
       addtion of six levels should be a significant
       improvement. While all six levels may not be needed in the
       short term, it is apparent that the original designers of IS-IS
       reserved enough space for these levels, and defining six
       additional levels is only slightly harder than adding a single
       level, so it makes some sense to expand the design for the
       future.
     </t>
     <t>
       The modifications described herein are designed to be fully
       backward compatible.
     </t>
     <t>
       Section references in this document are references to sections
       of <xref target="ISO10589">IS-IS</xref>.
     </t>

     <section title="Requirements Language">
       <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 <xref
       target="RFC2119">RFC 2119</xref>.</t>
     </section>
   </section>

   <section title="PDU changes">
     <t>
       In this section, we enumerate all of the redefinitions of
       protocol header fields necessary to add additional levels.
     </t>
     <section title="Circuit Type">
       <t>
	 In the fixed header of some IS-IS PDUs, a field is named
	 'Reserved/Circuit Type' (Section 9.5). The high order six
	 bits are reserved, with the low order two bits indicating
	 Level 1 (bit 1) and Level 2 (bit 2).
       </t>
       <t>
	 This field is renamed to be 'Circuit Type'. The bits are
	 redefined as follows:
	 <list style="numbers">
	   <t> Level 1 </t>
	   <t> Level 2 </t>
	   <t> Level 3 </t>
	   <t> Level 4 </t>
	   <t> Level 5 </t>
	   <t> Level 6 </t>
	   <t> Level 7 </t>
	   <t> Level 8 </t>
	 </list>
	 The value of zero (no bits set) is reserved. PDUs with a
	 Circuit Type of zero SHALL be ignored.
       </t>
       <t>
	 The set bits of the Circuit Type MUST be contiguous. If bit n
	 and bit m are set in the Circuit Type, then all bits in the
	 interval [n:m] must be set.
       </t>
     </section>
     <section title="PDU Type">
       <t>
	 The fixed header of IS-IS PDUs contains an octet with three
	 reserved bits and the 'PDU Type' field. The three reserved
	 bits are transmitted as zero and ignored on receipt. (Section
	 9.5)
       </t>
       <t>
	 To allow for additional PDU space, this entire octet is
	 renamed the 'PDU Type' field.
       </t>
     </section>
   </section>
   <section title="Additional PDUs">
     <section title="LAN IS to IS hello PDU (LAN-HELLO-PDU)">
       <t>
	 The 'LAN IS to IS hello PDU' (LAN-HELLO-PDU) is identical in
	 format to the 'Level 2 LAN IS to IS hello PDU' (Section 9.6),
	 except that the PDU Type has value AAA. The LAN-HELLO-PDU
	 MUST be used instead of the 'Level 1 LAN IS to IS hello PDU'
	 (Section 9.5) or the 'Level 2 LAN IS to IS hello PDU' on any
	 circuit that has one or more of Level 3 through Level 8
	 enabled.
       </t>
     </section>
     <section title="Point-to-point IS to IS hello PDU (P2P-HELLO-PDU)">
       <t>
	 The 'Point-to-point IS to IS hello PDU' can be used on
	 circuits of any Level without modification.
       </t>
     </section>
     <section title="Level n Link State PDU (Ln-LSP-PDU)">
       <t>
	 The 'Level n Link State PDU' (Ln-LSP-PDU) has the same format
	 as the 'Level 2 Link State PDU' (Section 9.9), except for the
	 PDU Type. The PDU Types for Levels 3 through 8 are defined as
	 follows:
	 <list>
	   <t> Level 3 (L3-LSP-PDU): BBB </t>
	   <t> Level 4 (L4-LSP-PDU): CCC </t>
	   <t> Level 5 (L5-LSP-PDU): DDD </t>
	   <t> Level 6 (L6-LSP-PDU): EEE </t>
	   <t> Level 7 (L7-LSP-PDU): FFF </t>
	   <t> Level 8 (L8-LSP-PDU): GGG </t>
	 </list>
       </t>
     </section>
     <section title="Level n complete sequence numbers PDU (Ln-CSNP-PDU)">
       <t>
	 The 'Level n complete sequence numbers PDU' (Ln-CSNP-PDU) has
	 the same format as the 'Level 2 complete sequence numbers
	 PDU' (Section 9.11), except for the PDU Type. The PDU Types
	 for Levels 3 through 8 are defined as follows:
	 <list>
	   <t> Level 3 (L3-CSNP-PDU): HHH </t>
	   <t> Level 4 (L4-CSNP-PDU): III </t>
	   <t> Level 5 (L5-CSNP-PDU): JJJ </t>
	   <t> Level 6 (L6-CSNP-PDU): KKK </t>
	   <t> Level 7 (L7-CSNP-PDU): LLL </t>
	   <t> Level 8 (L8-CSNP-PDU): MMM </t>
	 </list>
       </t>
     </section>
     <section title="Level n partial sequence numbers PDU (Ln-PSNP-PDU)">
       <t>
	 The 'Level 2 partial sequence numbers PDU' (Ln-PSNP-PDU) has
	 the same format as the 'Level 2 partial sequence numbers PDU'
	 (Section 9.13), except for the PDU Type.  The PDU Types
	 for Levels 3 through 8 are defined as follows:
	 <list>
	   <t> Level 3 (L3-PSNP-PDU): NNN </t>
	   <t> Level 4 (L4-PSNP-PDU): OOO </t>
	   <t> Level 5 (L5-PSNP-PDU): PPP </t>
	   <t> Level 6 (L6-PSNP-PDU): QQQ </t>
	   <t> Level 7 (L7-PSNP-PDU): RRR </t>
	   <t> Level 8 (L8-PSNP-PDU): SSS </t>
	 </list>
       </t>
     </section>

   </section>

   <section title='Inheritance of TLVs'>
     <t>
       All existing Level 2 TLVs may be used in the corresponding
       Level 3 through Level 8 PDUs. When used in a Level 3 through
       Level 8 PDU, the semantics of these TLVs will be applied to the
       Level of the containing PDU. If the original semantics of the
       PDU was carrying a reference to Level 1 in a Level 2 TLV, then
       the semantics of the TLV at level N will be a reference to
       level N-1. The intent is to retain the original semantics  of
       the TLV at the higher level.
     </t>
   </section>

   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>
       The author would like to thank Dinesh Dutt for inspiring this document.
     </t>

   </section>

   <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" title="IANA Considerations">
     <t>
       This document makes many requests to IANA, as follows:
     </t>
     <section title="PDU Type">
       <t>
	 The existing IS-IS PDU registry currently supports values
	 0-31. This should be expanded to support the values
	 0-255. The existing value assignments should be
	 retained. Value 255 should be reserved.
       </t>
     </section>
     <section title="New PDUs">
       <t>
	 IANA is requested to allocate values from the IS-IS PDU
	 registry for the following:
	 <list>	
	   <t> LAN-HELLO-PDU: AAA </t>
	   <t> L3-LSP-PDU: BBB </t>
	   <t> L4-LSP-PDU: CCC </t>
	   <t> L5-LSP-PDU: DDD </t>
	   <t> L6-LSP-PDU: EEE </t>
	   <t> L7-LSP-PDU: FFF </t>
	   <t> L8-LSP-PDU: GGG </t>
	   <t> L3-CSNP-PDU: HHH </t>
	   <t> L4-CSNP-PDU: III </t>
	   <t> L5-CSNP-PDU: JJJ </t>
	   <t> L6-CSNP-PDU: KKK </t>
	   <t> L7-CSNP-PDU: LLL </t>
	   <t> L8-CSNP-PDU: MMM </t>
	   <t> L3-PSNP-PDU: NNN </t>
	   <t> L4-PSNP-PDU: OOO </t>
	   <t> L5-PSNP-PDU: PPP </t>
	   <t> L6-PSNP-PDU: QQQ </t>
	   <t> L7-PSNP-PDU: RRR </t>
	   <t> L8-PSNP-PDU: SSS </t>
	 </list>
	 To allow for PDU types to be defined independent of this
	 document, the above values should be allocated from the range 32-254.
       </t>
     </section>
   </section>

   <section anchor="Security" title="Security Considerations">
     <t>
       This document introduces no new security issues. Security of routing within
       a domain is already addressed as part of the routing protocols
       themselves. This document proposes no changes to those security
       architectures.
     </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 Routing 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 year="2002" month="Nov."/>
       </front>
       <seriesInfo name="ISO/IEC" value="10589:2002"/>
     </reference>

     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;

   </references>
</back>
</rfc>
