One document matched: draft-ietf-isis-oper-enhance-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- $Id$ -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY RFC2119 SYSTEM   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3373 SYSTEM   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3373.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes" ?>


<rfc category="info" docName="draft-ietf-isis-oper-enhance-03"
     ipr="trust200902" updates="">

  <front>
    <title abbrev="IS-IS Operational Enhancements">
      IS-IS Operational Enhancements for Network Maintenance Events
    </title>

    <author fullname="Naiming Shen" initials="N."
            surname="Shen">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>225 West Tasman Drive</street>
          <street/>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <email>naiming@cisco.com</email>
      </address>
    </author>

    <author fullname="Tony Li" initials="T."
            surname="Li">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>225 West Tasman Drive</street>
          <street/>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <email>tony.li@tony.li</email>
      </address>
    </author>

    <author fullname="Shane Amante" initials="S."
            surname="Amante">
      <organization>Level 3 Communications</organization>
      <address>
	    <postal>
          <street>1025 Eldorado Blvd</street>
          <street/>
          <city>Broomfield</city>
          <code>80021</code>
          <region>CO</region>
          <country>USA</country>
        </postal>
        <email>shane@level3.net</email>
      </address>
    </author>

    <author fullname="Mikael Abrahamsson" initials="M."
            surname="Abrahamsson">
      <organization>Tele2</organization>
      <address>
        <email>swmike@swm.pp.se</email>
      </address>
    </author>


    <date year="2013"/>
    <area>Routing</area>

    <workgroup>IS-IS Working Group</workgroup>

    <abstract>
      <t>
	This document describes an improved IS-IS neighbor management
	scheme which can be used to enhance operational experience in terms of
	convergence speed and finer control of neighbor cost over a LAN.
      </t>
    </abstract>
  </front>


  <middle>

    <section anchor="Intro" title="Introduction">
      <t>
	The IS-IS <xref target="ISO10589"/> routing protocol has been
	widely used in Internet Service Provider IP/MPLS networks.
	Operational experience with the protocol, combined with ever
	increasing requirements for lossless operations have demonstrated
	some operational issues.  This document describes those issues and
	some mechanisms for dealing with those issues.  These mechanisms do
	involve implementation support, but do not require protocol
	changes.
      </t>
      <section anchor='blackhole' title="Interface Shutdown Black Hole">
	<t>
	  One of these operationally problematic issues occurs when IS-IS
	  is disabled on only one side of a link.  This can result in a
	  significant delay before neighbor(s) on the other end of the same
	  link notice this change.  In turn, this can result in several
	  seconds during which traffic is blackholed, until the IS-IS
	  neighbor(s) time out the adjacency and IS-IS reconverges.
	</t>
      </section>
      <section anchor='lan' title="LAN of Last Resort">
	<t>
	  Another issue stems from a situation when operators want to
	  temporarily make an interface a "last resort" link for transit
	  traffic.  This is a straightforward, though cumbersome, operation
	  to perform on a point-to-point link.  Each device on the link is
	  reconfigured to use very high metric.  This causes traffic to
	  divert to other links in the network.  This same operation is more
	  difficult on a multi-access LAN.  There, the operator would have to
	  increase the metric on each and every interface attached to the
	  LAN, requiring the reconfiguration of a number of systems.
	</t>
      </section>

      <section anchor="Req" title="Specification of Requirements">
	<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"/>.
	</t>

      </section> <!-- EO Req -->
    </section> <!-- EO Intro -->

    <section anchor="Fast-Exit"
             title="Sending Hellos with Fast Exit Notification">
      <t>
	When an operator shuts down IS-IS on an interface, as described in
	<xref target='blackhole'/>, there is a significant interval before
	the change is noticed by all adjacencies and traffic is
	subsequently re-routed around this link.  This delay is
	unnecessary, as neighbors should not have to wait for the adjacency
	to timeout, particularly when there exist alternate, viable, paths
	to downstream neighbors.  This delay can be eliminated by carefully
	removing the adjacency between neighbors prior to actually
	disabling IS-IS on the interface.
      </t>
      <t>
	An IS-IS adjacency uses the 3-way handshake protocol as defined in
	<xref target="ISO10589"/> for multi-access LANs and
	<xref target="RFC3373"/> for point-to-point links.  In both cases,
	the IS to IS Hello (IIH) message is used to establish and maintain the
	adjacency carries the system identifier of the adjacent systems.
	The receiving system expects to see its own system identifier
	listed.  If not, then it must drop the adjacency.
      </t>
      <t>
	An implementation that wishes to avoid the issue in
	<xref target='blackhole'/> can do so by sending out a final IIH
	that includes no neighboring system IDs.  When this is received, it
	should cause all neighbors to drop their adjacencies with the
	router that sent the IIH.  This will also cause the systems to
	update their Link State Protocol Data Units (LSPs), flood them and
	reconverge to new paths.  The technique is known as Fast Exit
	Notification.
      </t>

    </section> <!-- EO Fast-Exit -->

    <section anchor="Pnode"
             title="Pseudonodes with Non-zero Metrics">

      <t>
	If an operator wishes to reconfigure a multi-access LAN so that it
	is only used as a resource of the last resort, then with current
	mechanisms, the operator must reconfigure each node on the LAN to
	give the LAN a high metric, as described in <xref target='lan'/>.
	It would be much easier for the operator if they could make a
	single configuration change that would cause IS-IS to treat the
	multi-access LAN as a link of last resort.
      </t>
      <t>
	<xref target="ISO10589"/> defines the pseudonode LSP as having a
	metric of zero.  This implies that during the Shortest Path First
	(SPF) calculation, the metric for traversing the LAN is solely
	based on the metric set by the IS used to access the LAN.  Thereby,
	the pseudonode does not contribute to the cost of traversing the
	LAN.
      </t>
     
    <t>However, from the point of view of the SPF calculation, the
    metric in the pseudonode LSP does not have to be zero. Instead, the
    metric in a pseudonode LSP could be treated just like a normal LSP
    and have non-zero metrics to some or all of the systems on the LAN.
    This can then be used to simplify the operation for turning an
    entire LAN into a link of last resort. This could be done by having
    the Designated Intermediate System (DIS) change all of the metrics
    within the pseudonode LSP to a high value. This would effectively
    make the entire LAN look very 'expensive' and cause SPF
    calculations to converge to alternate links, if at all possible.</t>
      
    <t>This technique can also be used to divert traffic away from a
    subset of the nodes on the LAN. If the DIS increases the metric
    from the pseudonode to a subset of the systems on the LAN, then
    traffic will avoid exiting the LAN via that subset of systems.</t>

    <section anchor="pnode-alt" title="Alternative Approaches">

    <t>An alternative is to allow any system to temporarily become the
    DIS, when it is directed to, and set a non-zero metric in the
    pseudonode LSP(s). This is beneficial because the operator would
    otherwise first have to determine the current DIS, access that
    system and reconfigure it. If an implementation wishes to support
    this, it can provide an operation that both changes its
    priority on the LAN, so that a node first becomes DIS, and then
    generates a new pseudonode LSP with the non-zero metric.</t>
    
    <t>If there is a concern that the DIS may change, it is prudent to
    define another node on the same LAN with the second highest
    priority for becoming DIS. This node can be configured to also set
    the metric in its pseudonode LSP appropriately if it becomes the
    new DIS.</t>

      </section> <!-- EO pnode-alt -->
    </section> <!-- EO Pnode -->

    <section anchor="oper" title="Operational Considerations">

    <section anchor="oper-fen" title="Operational Considerations: Fast Exit Notification">

    <t>The approach described in <xref target="Fast-Exit" /> is not
    guaranteed. If the final IIH is lost on the link, then the
    neighboring systems will have to wait to time out the adjacency.
    Since this is unlikely, it is still a useful optimization.
    Implementations that require an even higher degree of assurance can
    retransmit the final IIH, possibly multiple times.</t>
    
    </section> <!-- EO oper-fen -->
    
    <section anchor="oper-nz-pnode" title="Operational Considerations: Pseudonodes with Non-zero Metrics">

    <t>Because the change to the usage of the pseudonode LSP, as
    described in <xref target="Pnode" />, is in direct contradiction to
    the existing IS-IS specification, extreme caution is necessary.
    Implementations that would not interpret a non-zero pseudonode
    metric correctly might cause forwarding loops. Operators should
    perform Lab testing and take caution when deploying this feature to
    ensure that nodes that receive a non-zero pseudonode metric will
    interpret it correctly.</t>
    
    </section> <!-- EO oper-nz-pnode -->
    
    </section> <!-- EO oper -->

    <section anchor="Security"
             title="Security Considerations">
      <t>
	This document raises no new security issues for IS-IS.
      </t>

    </section> <!-- EO Security -->



    <section anchor="Acknowledgements"
             title="Acknowledgements">

      <t>The authors would like to thank Mike Shand, Dave Katz, Guan
      Deng, Ilya Varlashkin, Jay Chen, Peter Ashwood-Smith, Les
      Ginsberg, Danny McPherson, Ed Crabbe, Russ White and Robert
      Raszuk for their reviews and contributions.</t>

    </section> <!-- Ack -->


  </middle>
  <back>

    <references title="Normative References">

    <reference anchor="ISO10589">
    <front>
        <title>
        Intermediate system to Intermediate system routeing information
        exchange protocol for use in conjunction with the Protocol for
        providing the Connectionless-mode Network Service (ISO
        8473)
        </title> 
        <author initials="" surname="" fullname="ISO">
            <organization >ISO</organization>
        </author>
        <date month="" year="" />
    </front>
    <seriesInfo name="ISO/IEC" value="10589:2002"/>
    </reference>

      &RFC2119;
      &RFC3373;

    </references>

  </back>
</rfc>