One document matched: draft-ietf-isis-purge-tlv-04.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">
	  <!ENTITY I-D.li-reg-purge SYSTEM
		   "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.li-reg-purge.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-04"
     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="September" day="1" 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 (POI) 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.
	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 POI 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>				

      <t>
	The POI TLV SHOULD be found in all purges and MUST NOT be found in
	LSPs with a non-zero Remaining Lifetime.
      </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'/> to further aid in the rapid
	identification of the system that generated the purge.  This TLV
	MAY be included in purges.  Implementations SHOULD include the
	Dynamic hostname TLV if the POI TLV is included.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
	Use of the extensions defined here with authentication as defined
	in <xref target='RFC5304'/> or <xref target='RFC5310'/> will result
	in the discarding of purges by legacy systems which are in strict
	conformance with either of those RFCs.  This may compromise the
	correctness/consistency of the routing database unless all ISs in
	the network support these extensions.  NEW TEXT: Therefore, all
	implementations in a domain implementing authentication MUST be
	upgraded to receive the POI TLV before any IS is allowed to
	generate a purge with the POI TLV.
      </t>
      <t>
	More interactions between the POI TLV, the Dynamic hostname TLV,
	and the Authentication TLV are described in
	<xref target='I-D.li-reg-purge'/>.
      </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 code point 13 for the
	'Purge Originator Identification' TLV from the IS-IS 'TLV
	Codepoints Registry'.  The additional values for this TLV should
	be: IIH:n, LSP:y, SNP:n, Purge:y.
      </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>

      &I-D.li-reg-purge;

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