rfc-6232

Purge Originator Identification TLV for IS-IS

F. Wei, Y. Qin, Z. Li, T. Li, J. Dong

date2011-05 streamIETF areartg wgisis statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6232 doi10.17487/RFC6232

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. 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 Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge. This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

updated by

rfc-8918 — Invalid TLV Handling in IS-IS

updates

rfc-5301 — Dynamic Hostname Exchange Mechanism for IS-IS
rfc-5304 — IS-IS Cryptographic Authentication
rfc-5310 — IS-IS Generic Cryptographic Authentication

Extracted elements (10)

design-rationale §1

IS-IS floods purges throughout an area without identifying which IS initiated the purge, making it difficult for network operators to locate the purge origin. Field experience identified implementation deficiencies and pre-ISO-TC1 implementations that improperly generate purges upon receiving corrupted LSPs as the motivating scenarios.

routing

interoperability-note §5

Legacy systems strictly conforming to RFC 5304 or RFC 5310 will discard purges carrying the new POI TLV when authentication is in use, because the additional TLV changes the authenticated content. A coordinated domain-wide upgrade is required before deployment.

routing, security

normative-requirement §3 SHOULD

If an IS generates a purge, it SHOULD include the POI TLV in the purge with its own system ID.

routing

normative-requirement §3 SHOULD

If an IS receives a purge that does not include the POI TLV, it SHOULD add this TLV with both its own system ID and the system ID of the IS from which it received the purge, thereby recording the upstream source.

routing

normative-requirement §4 SHOULD

Implementations SHOULD include one instance of the Dynamic hostname TLV in a purge if the POI TLV is included.

routing

normative-requirement §3 MUST NOT

The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non-zero Remaining Lifetime.

routing

protocol-element §4

The Dynamic hostname TLV (type 137, RFC 5301) is extended for use in purges to aid rapid identification of the purge originator. Only the local hostname should be inserted; implementations SHOULD include one instance if the POI TLV is included.

routing

registry §6

IANA assigned code point 13 to the 'Purge Originator Identification' TLV in the IS-IS 'TLV Codepoints' registry, with applicability flags IIH:n, LSP:y, SNP:n, Purge:y.

routing, registry

security-consideration §5 MUST

Using the POI TLV with authentication (RFC 5304 or RFC 5310) will cause legacy systems in strict conformance with those RFCs to discard purges, potentially compromising routing database consistency. Therefore, all implementations in an authentication domain MUST be upgraded to receive the POI TLV before any IS is permitted to generate a purge containing it.

routing, security

wire-format §3

The Purge Originator Identification (POI) TLV is CODE 13, with a LENGTH field covering the total value, a 1-octet count of system IDs (values 1 or 2 only), the system ID of the IS that inserted the TLV, and an optional system ID of the IS from which the purge was received.

routing