LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)
Extracted elements (29)
In PBB-VPLS, simply using RFC 4762 B-MAC flushing to address I-component topology changes causes excessive, unnecessary B-MAC flushing in the backbone even though the backbone itself has not failed. The MAC Flush Parameters TLV with C=1 allows I-component events to propagate through B-VPLS infrastructure without triggering spurious B-MAC flush actions.
LDP-based capability negotiation for MAC flush support was considered but deemed outside scope. Instead, the document relies on operator configuration responsibility: operators must ensure all VPLS devices support the optimization before enabling it, and implementations should provide per-PE administrative control over which flushing mode is used.
The document introduces 'negative' MAC flushing ('flush-all-from-me', N=1) as an optimization over the RFC 4762 'positive' MAC flushing ('flush-all-but-mine', N=0). In positive flushing, a PE receiving a flush discards all MACs except those on the receiving PW, causing unnecessary flooding across many VPLS instances; negative flushing scopes the flush only to MACs learned from the failing PE's specific PW.
The MAC flushing mechanism initiated by the MTU-s is modeled after the Topology Change Notification (TCN) in RSTP (IEEE 802.1Q). When a bridge switches from a failed link to its backup, it sends a TCN message over the newly activated link, causing the upstream bridge to flush MAC addresses except those received on that link.
If a BEB in PBB-VPLS receives a MAC Flush Parameters TLV it does not understand, undesirable MAC flushing may result. The U-bit and F-bit are both set to 1 so that intermediate devices unaware of the TLV propagate it transparently rather than dropping it.
In Multi-Segment Pseudowire (MS-PW) deployments within VPLS, MAC flush messages are processed only at PW Terminating Provider Edge (T-PE) nodes; PW Switching Provider Edge (S-PE) nodes propagate MAC flush messages without taking any action. All PE-rs references in Section 5.1.3 apply only to T-PE nodes in the MS-PW case.
The optimized MAC flush solution is generic and applicable when Multi-Segment Pseudowires (MS-PWs) per RFC 6073 are used to interconnect PE devices in H-VPLS. The solution also applies to native Ethernet access topologies (e.g., ITU-T G.8032 rings, multi-chassis LAG) multi-homed to two or more VPLS PE-rs devices.
A PE-rs device receiving a MAC Flush TLV with N=1 SHOULD flush all MAC addresses learned from the PW on which the MAC flush message was received within the specified VPLS context.
At least one of the PBB B-MAC List Sub-TLV or PBB I-SID List Sub-TLV MUST be included in the MAC Flush Parameters TLV when the C-flag is set to 1 (I-component context).
If the optimized MAC flush procedure is used in a Backbone VPLS or regular VPLS/H-VPLS context, the C-bit MUST be ZERO (C=0). If used in an I-component context, the C-bit MUST be set (C=1).
In negative MAC flushing, the MAC list SHOULD contain only the MACs for the affected MTU-s. If the list is empty, the negative MAC flush will result in flushing and relearning all attached MTU-s devices for the originating PE-rs.
It is RECOMMENDED that all PE-rs devices participating in PBB-VPLS support the MAC Flush Parameters TLV. If not possible, the MAC Flush Parameters TLV SHOULD be disabled, reverting to RFC 4762 flushing at the Backbone MAC level.
On Backbone Core Bridges (BCBs), if the C-bit is set to 1, the PBB-VPLS SHOULD NOT flush their B-MAC FIBs. The B-VPLS control plane SHOULD propagate the MAC flush message following data-plane split-horizon rules to the established B-VPLS topology.
On Backbone Edge Bridges (BEBs) with N=0 (positive flush): all C-MACs in selected I-SID FIBs SHOULD be flushed except those associated with B-MACs listed in the B-MAC List Sub-TLV. With N=1 (negative flush): only C-MACs associated with B-MACs in the B-MAC List Sub-TLV SHOULD be flushed.
Regardless of whether optimized MAC flushing is supported, if a PE-rs device receives a MAC flush message with a MAC Flush TLV option (N=0 or N=1) and a valid (non-empty) MAC address list, it SHOULD ignore the TLV option and process MAC addresses explicitly per RFC 4762.
The MAC Flush TLV SHOULD be placed after the existing TLVs in the RFC 4762 MAC flush message. MBZ flags (bits 2–7) SHOULD be set to zero on transmission and ignored on reception.
The PE-rs that supports the MAC Flush Parameters TLV MUST support the RFC 4762 MAC flushing procedures, since this document only augments them. Implementations SHOULD provide administrative control to select the desired MAC flushing action towards each PE-rs device.
The positive MAC flush message (flush-all-but-mine) from RFC 4762 MUST always be handled for Backbone MACs (B-MACs) in cases where core nodes change or fail. The optimized procedures in this document augment but do not replace RFC 4762 for those cases.
When optimized MAC flushing is not supported, the MAC withdraw procedures defined in RFC 4762 (MTU-s or PE2-rs sends the MAC withdraw message) SHOULD be used. This applies during network upgrades when not all devices support the optimized solution.
When optimized MAC flushing is supported, the MAC Flush TLV MUST be sent in an LDP address withdraw message with an empty MAC list by the core PE-rs upon detection of failure of its local/primary spoke PW. The N-bit MUST be set to 1 to indicate flush-all-from-me.
For negative MAC flushing in PBB-VPLS (N=1, C=1), the I-SID list SHOULD be specified (absent means all I-SIDs), and a B-MAC list SHOULD be included to scope the flush to specific B-MAC-to-C-MAC associations. This models the typical scenario where a PBB VPLS I-component interface has one I-SID and one or more B-MACs with multiple remotely learned C-MACs.
The MAC flush message propagation follows data-plane split-horizon rules in H-VPLS: a MAC flush message received in the context of a spoke PW is propagated on mesh PWs, but a MAC flush message received in the context of a mesh PW is not propagated to other mesh PWs.
The PBB B-MAC List Sub-TLV (type 0x0407) carries one or more 48-bit Backbone MAC addresses representing the source B-MACs associated with the B-VPLS instance that originated the MAC withdraw message. At least one B-MAC address MUST be present.
The PBB I-SID List Sub-TLV (type 0x0408) carries one or more 24-bit I-SIDs identifying the I-component FIBs where MAC flushing should occur. A zero-length value (empty I-SID list) means flushing applies to all I-SIDs mapped to the B-VPLS indicated by the FEC TLV.
IANA allocated three new code points in the LDP TLV Type Name Space: 0x0406 (MAC Flush Parameters TLV), 0x0407 (PBB B-MAC List Sub-TLV), and 0x0408 (PBB I-SID List Sub-TLV), all referencing RFC 7361.
IANA created a new sub-registry 'MAC Flush Flags' under LDP Parameters. Bit 0 (0x80) is the C-flag (Context), bit 1 (0x40) is the N-flag (Negative MAC flushing), bits 2–7 are unassigned. New bits are assigned by Standards Action per RFC 5226.
LDP security (authentication) methods described in RFC 5036 are applicable. The extensions optimize MAC flushing and reduce overall risk; however, if support for the new MAC Flush TLV can be spoofed, sub-optimal (but not catastrophic) MAC flushing behavior will result. The specification has no impact on the VPLS data-plane forwarding.
The Flags byte within the MAC Flush Parameters TLV contains two defined bits: C-flag (bit 0, 0x80) indicates PBB context (B-VPLS vs I-component), and N-flag (bit 1, 0x40) indicates positive (N=0, flush-all-but-mine) or negative (N=1, flush-all-from-me) MAC flush action. Bits 2–7 are MBZ.
The MAC Flush Parameters TLV (type 0x0406) is encoded with a 2-byte type field (U-bit and F-bit both set to 1 for forward-if-unknown), a 2-byte Length field, a mandatory 1-byte Flags field, and zero or more sub-TLVs. The U/F bits ensure intermediate devices unaware of the TLV propagate it transparently.