Controlling State Advertisements of Non-negotiated LDP Applications
updated by
- rfc-8223 — Application-Aware Targeted LDP
Extracted elements (26)
IP address bindings (ADDRESS messages) are deliberately excluded from the uninteresting state category for Prefix-LSPs. LSRs such as mLDP use peer IP addresses to determine upstream LSRs toward the root node and to select forwarding interfaces toward downstream LSRs; disabling IP address advertisement would break mLDP and other dependent applications.
Once the SAC capability is advertised it cannot be withdrawn (S-bit always 1). Application state advertisement can be re-enabled or re-disabled dynamically by sending updated capability TLVs, but the capability itself persists for the lifetime of the session.
The SAC capability is unilateral and unidirectional: a receiving LSR is not required to send a similar SAC capability back to the sender. This conforms to the unilateral procedures defined in Section 6 of RFC 5561, keeping the mechanism simple while still achieving the goal of suppressing unwanted state.
Dynamic changes to application state advertisement after session initialization require both peers to support LDP 'Dynamic Announcement Capability' (RFC 5561). If either peer lacks this support, the only alternative is to force-reset the LDP session so that the new SAC capability can be advertised in the following Initialization message.
In an mLDP-only session, disabling Prefix-LSPs suppresses IP Prefix FEC label bindings but IP address bindings (ADDRESS messages) continue to be advertised, which is required for correct mLDP upstream LSR selection. Operators deploying mLDP-only sessions should be aware that ADDRESS message exchange is not suppressed by this capability.
When dynamically disabling Prefix-LSPs on an established session, the withdrawing peer MAY use a single Prefix FEC Typed Wildcard Label Withdraw message (RFC 5918) to efficiently withdraw all previously advertised bindings, provided the peer supports the Typed Wildcard FEC capability.
A receiving LSR MUST treat each incoming SAC Capability TLV element corresponding to a given application type as an update to its existing outbound policy for that type, not as a replacement of the whole policy.
After the SAC capability is successfully negotiated, the receiving LSR MUST NOT advertise any state related to the disabled applications towards the capability-sending LSR until and unless those application states are explicitly re-enabled via a capability update.
An operator MUST NOT disable Prefix-LSP state on any Targeted LDP (tLDP) session established for reasons related to remote Loop-Free Alternate (LFA) Fast Re-Route (FRR). In a remote network that is LFA FRR enabled, it is RECOMMENDED not to disable Prefix-LSP state on a tLDP session even if the current session type is PW-only or ICCP-only.
An operator SHOULD disable Prefix-LSP state on any Targeted LDP session established for ICCP-only or PW-only purposes, as exchanging IP label bindings on such sessions is unnecessary.
If a receiving LDP speaker does not understand the SAC Capability TLV, it MUST respond to the sender with an 'Unsupported TLV' notification as described in RFC 5561.
If a SAC Capability TLV contains more than one SAC Element, each element MUST belong to a distinct application type — the same App type MUST NOT appear more than once. A receiver of a malformed TLV with duplicate app types SHOULD discard that TLV and continue processing the rest of the message.
If an LSR receives a SAC Capability TLV containing an element with an App field value not defined in the specification, the receiver MUST ignore and discard that element and continue processing the rest of the TLV. If a receiver does not understand or support an application in a control element, it SHOULD silently skip such an element.
The SAC capability and its procedures SHOULD be enabled on an LSR only via a configuration knob (global or per-neighbor), and an operator SHOULD enable this capability only when it is known that state advertisement with that neighbor is unnecessary and wasteful.
The SAC capability SHOULD be enabled for Prefix-LSPs only when it is desirable to disable all prefix label bindings. For scenarios requiring filtering of a subset of bindings, existing label binding filtering policies should be used instead.
The U-bit of the SAC Capability TLV MUST be set to 1 so that a receiver silently ignores the TLV if unknown. The F-bit MUST be set to 0. The S-bit MUST be set to 1 in both Initialization and Capability messages because once advertised this capability cannot be withdrawn.
Upon receipt of a capability update that disables a previously enabled application state during session lifetime, the receiving LSR MUST also withdraw from the peer any previously advertised state corresponding to the disabled application.
When included in an Initialization message, the D-bit in each SAC Element MUST be set to 1 (disable). Enabling a previously disabled application can only be done via a subsequent Capability message, not in an Initialization message.
For P2P-PWs, uninteresting state includes any state related to P2P PW FEC 128 and FEC 129, including FEC label bindings, MAC address withdrawal, and LDP PW Status messages.
For Prefix-LSPs, uninteresting state includes IP Prefix FEC label bindings and LDP Status, but explicitly excludes IP address bindings (ADDRESS messages). IP address bindings are still advertised because other applications such as mLDP rely on peer IP addresses for upstream LSR selection.
RFC 7473 defines the State Advertisement Control (SAC) Capability TLV (type 0x050D) that allows an LDP speaker to announce to its peer which non-negotiated application states (Prefix-LSPs and/or P2P-PWs) it does not wish to receive. The TLV carries one or more SAC Elements, each controlling a specific application. This capability is built on the LDP Capabilities framework (RFC 5561).
The two non-negotiated LDP applications covered are: (1) Prefix-LSPs — LDP LSPs for IP unicast prefixes advertised via Prefix FEC (RFC 5036); and (2) P2P-PWs — L2VPN point-to-point pseudowire signaling using FEC 128 and FEC 129 (RFC 4447). These predate LDP capabilities negotiation and advertise state without prior capability exchange.
IANA assigned TLV type value 0x050D ('State Advertisement Control Capability') from the 'TLV Type Name Space' sub-registry of the 'Label Distribution Protocol (LDP) Parameters' registry. This is the only IANA action required by this document.
RFC 7473 does not introduce any new security considerations beyond those that already apply to the base LDP specification (RFC 5036) and the MPLS/GMPLS security framework (RFC 5920). The SAC capability only suppresses state advertisement and does not alter authentication or integrity mechanisms.
Each SAC Element is a single octet: the high-order D-bit (1=disable, 0=enable), a 3-bit App field (1=IPv4 Prefix-LSPs, 2=IPv6 Prefix-LSPs, 3=FEC 128 P2P-PW, 4=FEC 129 P2P-PW), and 4 unused bits that MUST be zero on transmit and ignored on receipt.
The SAC Capability TLV has a 2-octet type field (0x050D) with U-bit and F-bit, a 2-octet Length field, a 1-octet flags field (S-bit + 7 reserved bits), followed by one or more 1-octet SAC Elements. Length in octets equals 1 plus the number of SAC elements.