One document matched: draft-ietf-isis-purge-tlv-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	  <!ENTITY RFC5301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5301.xml">
	  <!ENTITY RFC5304 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5304.xml">
	  <!ENTITY RFC5310 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5310.xml">
	  ]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="std" docName="draft-ietf-isis-purge-tlv-03"
     ipr="trust200902" updates="5301, 5304, 5310">

  <front>
    <title abbrev="Purge Originator Identification TLV">
      Purge Originator Identification TLV for IS-IS
    </title>

    <author initials="F" surname="Wei" fullname="Fang Wei">
      <organization>China Mobile</organization>
      <address><postal>
	  <street>No. 29, Financial Street, Xicheng District</street>
	  <city>Beijing</city><code>100032</code><country>P.R. China</country>
	</postal>
	<email>weifang@chinamobile.com</email>
      </address>
    </author>

    <author initials="Y" surname="Qin" fullname="Yue Qin">
      <organization>China Mobile</organization>
      <address><postal>
	  <street>No. 29, Financial Street, Xicheng District</street>
	  <city>Beijing</city><code>100032</code><country>P.R. China</country>
	</postal>
	<email>qinyue@chinamobile.com</email>
      </address>
    </author>

    <author initials="Z" surname="Li" fullname="Zhenqiang Li">
      <organization>China Mobile</organization>
      <address><postal>
	  <street>
	    Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu
	    District
	  </street>  
	  <city>Beijing</city><code>100053</code><country>P.R. China</country>
	</postal>
	<email>lizhenqiang@chinamobile.com</email>
      </address>
    </author>

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

    <author initials="J" surname="Dong" fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address><postal>
	  <street>KuiKe Building, No.9 Xinxi Rd., Haidian District</street>
	  <city>Beijing</city><code>100085</code><country>P.R. China</country>
	</postal>
	<email>dongjie_dj@huawei.com</email>
      </address>
    </author>

    <date month="June" day="15" year="2010"/>
    <area>Routing</area>
    <workgroup>IS-IS Working Group</workgroup>
    <abstract>
      <t>
	At present an IS-IS purge does not contain any information
	identifying the Intermediate System (IS) that generates the
	purge. This makes it difficult to locate the source IS.
      </t>
      <t>
	To address this issue, this document defines a TLV to be added to
	purges to record the system ID of the IS generating it.  Since
	normal LSP flooding does not change LSP contents, this TLV should
	propagate with the purge.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
	The IS-IS <xref target='ISO 10589'/> routing protocol has been
	widely used in large-scale IP networks because of its strong
	scalability and fast convergence.
      </t>
      
      <t>
	The IS-IS protocol floods purges throughout an area, regardless of
	which IS initiated the purge. If a network operator would like to
	investigate the cause of the purge, it is difficult to determine
	the origin of the purge. At present the IS-IS protocol has no
	mechanism to locate the originator of a purge. To address this
	problem, this document defines a TLV to be added to purges to
	record the system ID of the IS generating the purge.
      </t>

      <t>
	Field experience has observed several circumstances where an IS can
	improperly generate a purge.  These are all due to implementation
	deficiencies or implementations that predate <xref target='ISO TC1'/>
	and generate a purge when they receive a corrupted LSP.
      </t>

    </section>

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

    <section title="The Purge Originator Identification TLV">		
      <t>
	This document defines a TLV to be included in purges.  If an IS
	generates a purge, it SHOULD include this TLV in the purge with its
	own system ID.  If an IS receives a purge that does not include
	this TLV, then it SHOULD add this TLV with both its own system ID
	and the system ID of the IS that it received the purge from. 
      </t>
      <t>
	This allows ISs receiving purges to log the system ID of the
	originator, or the upstream source of the purge.  This makes it
	much easier for the network administrator to locate the origin of
	the purge and thus the cause of the purge.  Similarly, this TLV is
	helpful to developers in lab situations.
      </t>

      <t>
	The Purge Originator Identification TLV is defined as:
      </t>
      
      <t>
	CODE - 13
      </t>
      
      <t>
	LENGTH - total length of the value field.
      </t>
      
      <t>
	VALUE -
	<list>
	  <t>
	    Number of system IDs carried in this TLV (1 octet) -- Only the 
	    values 1 and 2 are defined.
	  </t>
	  <t>
	    System ID of the Intermediate System that inserted this TLV.
	  </t>
	  <t>
	    System ID of the Intermediate System that the purge was
	    received from.  (optional)
	  </t>
	</list>
      </t>				
    </section>

    <section title="Using the Dynamic Hostname TLV in Purges">
      <t>
	This document also extends the use of the Dynamic hostname TLV
	(type 137) <xref target='RFC5301'/>.  This TLV MAY also be included
	in purges.  This will further aid in the rapid identification of
	the system that generated the purge.
      </t>
      <t>
	Implementations SHOULD include the Purge Originator Identification
	TLV in addition to the Dynamic hostname TLV.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
	If the Purge Originator Identification TLV or the Dynamic hostname
	TLV is used in conjunction with IS-IS authentication mechanisms
	<xref target='RFC5304'/><xref target='RFC5310'/>, the purge LSP is
	constructed or modified as follows.  First, the original contents
	of the LSP are removed, leaving only the LSP header, then the Purge
	Originator Identification TLV and/or the Dynamic hostname TLV are
	added, and then the IS-IS authentication TLV is added.
      </t>
      <t>
	Legacy systems that implement <xref target='RFC5304'/> or
	<xref target='RFC5310'/> MUST discard purges with these additional
	TLVs.  This is not thought to be a significant operational issue as
	the loss of purges is typically not critical.
      </t>
    </section>

    <section title="Functional Changes">
      <t>
	This document amends the behavior specified in
	<xref target='RFC5301'/>, <xref target='RFC5304'/> and
	<xref target='RFC5310'/>.  ISs that receive purges with the Purge
	Originator Identification TLV or the Dynamic hostname TLV with
	valid authentication MUST NOT discard the PDU and SHOULD process it
	normally. The Purge Originator Identification TLV or Dynamic
	hostname TLV MUST NOT be removed from the purge prior to
	propagation.  If multiple purges are received for the same LSP
	fragment, then the implementation MAY propagate any one of the
	purges.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
	RFC EDITOR NOTE: This section to be removed upon publication.
      </t>
      <t>
	This document requests that IANA assign a code point for this TLV
	from the IS-IS 'TLV Codepoints Registry'.
      </t>
    </section>

    <section title="Acknowledgments">
      <t>
	Many thanks to Adrian Farrel and Daniel King for your comments to
	improve this document and move it forward.
      </t>
      <t>
	The first version of this document was mainly composed by Lianyuan Li.
      </t>
      <t>
	Acknowledgments to the discussion in the mailing list. Some
	improvements of this document are based on the discussion.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="ISO 10589">
	<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 fullname="ISO">
	    <organization >ISO</organization>
	  </author>
	</front>
        <seriesInfo name="ISO/IEC" value="10589:2002"/>
      </reference>

      <reference anchor='ISO TC1'>
	<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) -- Technical Corrigendum 1
	  </title> 
          <author fullname="ISO">
	    <organization>ISO</organization>
	  </author>
	</front>
        <seriesInfo name="ISO/IEC" value="10589:1992/ Cor.1:1993"/>
      </reference>

      &RFC2119;
      &RFC5301;
      &RFC5304;
      &RFC5310;
    </references>
  </back>
</rfc>