Subject: Protocol Action: 'Purge Originator Identification TLV for IS-IS' to Proposed Standard (draft-ietf-isis-purge-tlv-05.txt)

From: The IESG <[email-masked]>
Date: Mon, 07 Mar 2011 10:27:15 -0800

The IESG has approved the following document:
- 'Purge Originator Identification TLV for IS-IS'
  (draft-ietf-isis-purge-tlv-05.txt) as a Proposed Standard

This document is the product of the IS-IS for IP Internets Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-isis-purge-tlv/

Technical Summary

At present an IS-IS purges do not contain any information
identifying the Intermediate System (IS) that generates the purge.
This makes it difficult to locate the source IS.

To address this issue, the purge-tlv 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.

This reg-purge draft documents which TLVs can appear in different types
of IS-IS PDUs, but does not document which TLVs can be found in zero
Remaining Lifetime LSP (a.k.a., purges). This document extends the
existing registry to record the set of TLVs that are permissible in
purges.

Working Group Summary

The idea of the purge TLV was first discussed in Dublin at IETF 72. The
initial view of the Working Group was that the extension was not
necessary. After a couple years of discussion and work on the idea,
consensus has been achieved.

Document Quality

There is one known implementation.

Personnel

   David Ward is the Document Shepherd for this document.
   Stewart Bryant is the Responsible Area Director.

RFC Editor Note

======
In the Abstract
OLD
Since normal LSP flooding does not change LSP contents, this TLV 
should propagate with the purge.

NEW
Since normal Link State Packet (LSP) flooding does not change LSP 
contents, this TLV should propagate with the purge.

This document updates RFC5301, RFC5304 and RFC5310.
END

======

In Introduction (para 3)

OLD
receive a corrupted LSP.
NEW
receive a corrupted Link State Packet (LSP).
END

======