Update of the Pseudowire Control-Word Negotiation Mechanism
obsoleted by
- rfc-8077 — Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
updates
Extracted elements (17)
RFC 4447's control-word negotiation has a bug: when a PE changes its preference from NOT PREFERRED to PREFERRED, if the peer had already advertised C=0, the PE will still send C=0 in its Label Mapping, resulting in 'not used' even though both endpoints are configured PREFERRED. This occurs because the previously received Label Mapping with C=0 drives the re-advertisement.
The fix is to inject a Label Request message into the renegotiation sequence so that the local PE can obtain a fresh Label Mapping from the remote PE reflecting its current (updated) control-word preference rather than relying on cached state. This resolves the stale C-bit problem without changing the core RFC 4447 negotiation algorithm.
The S-PE is given a passive role for processing Label Request messages (mirroring its passive role for Label Mapping messages defined in RFC 6073) because S-PEs lack complete interface-parameter information for the FEC, so they must relay rather than originate Label Request messages.
When a PE changes its control-word preference from PREFERRED to NOT PREFERRED (the reverse direction), the existing RFC 4447 Section 5.4.1 procedures are sufficient and no additional mechanism is required. The Label Request extension is only needed for the NOT PREFERRED to PREFERRED direction.
For multi-segment pseudowires, T-PEs behave the same as PEs in the single-segment case, but S-PEs must be upgraded to implement the Label Request forwarding mechanism defined in this document. S-PEs that are not upgraded will not correctly propagate the renegotiation.
This document is fully backward compatible with existing RFC 4447 implementations for single-segment pseudowires. A remote PE that already implements RFC 4447 and the RFC 5036 Label Request message can interoperate with a PE following the updated mechanism of this document.
After receiving the remote peer's Label Mapping message carrying the C bit in response to the Label Request, the local PE MUST follow the procedures in RFC 4447 Section 6 when sending its own Label Mapping message.
After releasing labels, the local PE MUST send a Label Request message to the peer PE and MUST wait until it receives a Label Mapping message containing the peer's current configured preference for control-word use.
If the local PE has previously sent a Label Mapping message, it MUST send a Label Withdraw message to the remote PE and wait until it receives a Label Release message from the remote PE before proceeding. The Label Release and Label Withdraw sends do not require a specific sequence relative to each other.
The S-PE MUST process the Label Withdraw message before the Label Request message. When the S-PE receives a Label Withdraw, it sends a Label Release in response and a Label Withdraw upstream, then processes subsequent LDP messages such as the Label Request.
When an S-PE receives a Label Release message from a remote PE during renegotiation, it MUST send a corresponding Label Release message to the other remote PE if it holds a label for the PW from that remote PE.
When an S-PE receives a Label Request message from one of its adjacent PEs during multi-segment PW control-word renegotiation, it MUST send a matching Label Request message to the other adjacent PE, because the S-PE does not have complete interface-parameter field information for the FEC advertisement.
When renegotiation begins (local PE changes from NOT PREFERRED to PREFERRED and has received a remote Label Mapping with C=0), the local PE MUST send a Label Release message to the remote PE.
The FEC element in the Label Request message must be the local PE's own PW FEC element. In response, the peer PE sends a Label Mapping with its own local PW FEC element. The Label Request message format and procedure are as specified in RFC 5036.
The security considerations of RFC 4447 and RFC 6073 apply in full to this document. This document does not introduce any additional security constraints beyond those already specified in the referenced documents.
Renegotiation state sequence for a PE changing control-word preference from NOT PREFERRED to PREFERRED: (1) send Label Release (and Label Withdraw + await Label Release if Label Mapping was previously sent); (2) send Label Request and await Label Mapping; (3) upon receipt of Label Mapping with current C bit, send own Label Mapping per RFC 4447 Section 6. The entire sequence must complete before processing further configuration changes.
The Appendix A diagram extends RFC 4447's C-bit handling: when control word changes from NOT PREFERRED to PREFERRED, the PE deletes and reconfigures the PW, sends Label Release and Label Withdraw, waits for Label Release, then sends Label Request. On receiving the remote Label Mapping, it proceeds with normal RFC 4447 C-bit resolution. A 'Wrong C-bit' branch triggers sending a new Label Mapping message.