Virtual B-MAC learning frames (for example, the frames sent with the source MAC set to the virtual B-MAC) can be sent periodically, allowing all BCBs/BEBs to keep the virtual B-MAC in their Layer 2 forwarding database.
This periodic mechanism is useful in the following cases:
A new BEB is added after the current mac-notification method has stopped sending learning frames.
When a new combination of [MC-LAG:SAP|A/S PW]+[PBB-Epipe]+[associated B-VPLS]+[at least one B-SDP|B-SAP] becomes active. The current mechanism only sends learning frames when the first such combination becomes active.
A BEB containing the remote endpoint of a dual-homed PBB-Epipe is rebooted.
When traffic is not seen for the MAC aging timeout (assuming that the new periodic sending interval is less than the aging timeout).
When there is unidirectional traffic.
In each of the above cases, all of the remote BEB/BCBs learn the virtual MAC in the worst case after the next learning frame is sent.
In addition, this allows all of the above when to be used in conjunction with discard-unknown in the B-VPLS. Currently, if discard-unknown is enabled in all related B-VPLSs (to avoid any traffic flooding), all above cases could experience an increased traffic interruption, or a permanent loss of traffic, as only traffic toward the dual homed PBB-Epipe can restart bidirectional communication. For example, it reduces the traffic outage when:
The PBB-Epipe virtual MAC is flushed on a remote BEB/BCB because of the failover of an MC-LAG or A/S pseudowires within the customer’s access network, for example, in between the dual homed PBB-Epipe peers and their remote tunnel endpoint.
There is a failure in the PBB core causing the path between the two BEBs to pass through a different BCB.
It should be noted that this does not help in the case where the remote tunnel endpoint BEB fails. In this case traffic is flooded when the remote B-MAC ages out if discard-unknown is disabled. If discard-unknown is enabled, then the traffic follows the path to the failed BEB but is eventually dropped on the source BEB when the remote B-MAC ages out on all systems.
To scale the implementation it is expected that the timescale for sending the periodic notification messages is much longer than that used for the current notification messages.