ietf-corpus

rfc-7026

Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel

A. Farrel, S. Bryant
date2013-09 streamIETF areartg wgmpls statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc7026 doi10.17487/RFC7026
The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

updates

Extracted elements (11)

design-rationale §1

ACH TLVs are retired because no ACH Channel Type defined at the time of writing uses them, and handling variable-length TLVs in hardware introduces significant problems to the fast path. Since G-ACh messages are intended to be processed substantially in hardware, ACH TLVs are considered undesirable.

mpls

design-rationale §1

Of the 18 ACH Channel Types defined at the time of writing, none allows the use of ACH TLVs, and there were no unexpired Internet-Drafts utilizing ACH TLVs. This absence of adoption confirms the feature is not useful.

mpls

design-rationale §1

The document deliberately excludes from scope any proposals to use TLVs within ACH messages or as an appendage to ACH messages; only the ACH TLV construct placed between the fixed ACH header fields and the G-ACh message is retired.

mpls

interoperability-note §5

Packet sniffers already implemented to look for ACH TLVs will not be negatively impacted by the deletion of the construct, since no ACH Types currently allow TLV use and the absence of TLVs is already the operational norm.

mpls

normative-requirement §3 MUST NOT

A G-ACh message MUST NOT be preceded by an ACH TLV. This directly deprecates the ACH TLV construct defined in RFC 5586 Section 3.

mpls

protocol-element §2

RFC 5586 Section 3, which defined ACH TLV constructs, is deleted in its entirety by this document. References to ACH TLVs in RFC 5586 Section 4 (which used phrases like 'ACH TLV(s), if present') should also be disregarded.

mpls

protocol-element §1

The MPLS Generic Associated Channel (G-ACh) provides a common encapsulation header for control channel messages associated with MPLS Sections, LSPs, and PWs, generalized from the Pseudowire Associated Channel Header (ACH) defined in RFC 4385.

mpls

registry §4.1

The 'Associated Channel Header TLV Registry' subregistry within 'Pseudowire Name Spaces (PWE3)' is entirely deleted by IANA. A tombstone record remains in the top-level registry list reading 'Associated Channel Header TLV Registry (DELETED)' referencing RFC 5586 and RFC 7026.

mpls, registry

registry §4.2

The 'Pseudowire Associated Channel Types' registry previously included a column marked 'TLV Follows'. IANA has entirely deleted this column, leaving no record, as part of retiring ACH TLVs.

mpls, registry

security-consideration §6

Deleting the ACH TLV has a marginal positive security effect because it removes a feature that could have been used as an attack vector to carry false information or to bloat G-ACh messages.

mpls, security

security-consideration §6

It was suggested that ACH TLVs could have carried security parameters to secure G-ACh messages generically, but no such mechanisms were proposed. Security requirements are considered the responsibility of each individual G-ACh message specification.

mpls, security