Technical Summary:
RFC4762 describes a mechanism to remove or unlearn MAC addresses that
have been dynamically learned in a Virtual Private LAN Service (VPLS)
Instance for faster convergence on topology change. The procedure
also removes MAC addresses in the VPLS that do not require relearning
due to such topology change.
This document defines new procedures for MAC flushing in VPLS, H-VPLS and PBB-
VPLS services upon access topology changes. These procedures cover additional
additional scenarios to that covered RFC 4762 for H-VPLS. MAC flushing is a
mechanism used to minimize traffic black-holing time when reachability to MAC
addresses changes due to topology access changes.
In particular, this document describes procedures for MTU-s initiated MAC flush
when MTU-s is dual-homed to provider edges (PEs) over an active and standby
Pseudowires, and the propagation of the MAC flush message over the VPLS core
and processing at PEs. It also describes a new optimized MAC flush mechanism
termed "negative flush" that enables PEs with instances of a VPLS instance to flush
the MAC entries reachable via the PE where the topology change was experienced.
This is opposed to the current procedure defined in RFC 4762 which cause all MAC
addresses previously learned to be flushed except those that are learned from the
PE that initiates the flush. Lastly, this document defines the MAC flush and optimized
MAC flush for PBB-VPLS services.
Working Group Summary:
This document is an L2VPN Working Group document. It has gone through a few
iterations that addressed comments received from the Working group and comments
from the WG chairs.
The draft got good support when it was adopted as a WG draft. The Working Group
last call got no feedback from the Working Group and the only comments that
needed to be addressed were those of the WG chairs.
Document Quality:
The document has OK quality. It is clear on the technical content and written with
reasonable English and layout.
The draft has authors from a couple companies that claim to have implemented the
solution albeit no interoperability testing was done.
Personnel:
Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.com)
Area Director: Adrian Farrel (Adrian@olddog.co.uk)