path: root/doc/rfc/rfc7361.txt

Internet Engineering Task Force (IETF)                          P. Dutta
Request for Comments: 7361                                      F. Balus
Category: Standards Track                                 Alcatel-Lucent
ISSN: 2070-1721                                                O. Stokes
                                                        Extreme Networks
                                                            G. Calvignac
                                                                  Orange
                                                                D. Fedyk
                                                         Hewlett-Packard
                                                          September 2014


          LDP Extensions for Optimized MAC Address Withdrawal
         in a Hierarchical Virtual Private LAN Service (H-VPLS)

Abstract

   RFC 4762 describes a mechanism to remove or unlearn Media Access
   Control (MAC) addresses that have been dynamically learned in a
   Virtual Private LAN Service (VPLS) instance for faster convergence on
   topology changes.  The procedure also removes MAC addresses in the
   VPLS that do not require relearning due to such topology changes.
   This document defines an enhancement to the MAC address withdraw
   procedure with an empty MAC list (RFC 4762); this enhancement enables
   a Provider Edge (PE) device to remove only the MAC addresses that
   need to be relearned.  Additional extensions to RFC 4762 MAC withdraw
   procedures are specified to provide an optimized MAC flushing for the
   Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7361.









Dutta, et al.                Standards Track                    [Page 1]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































Dutta, et al.                Standards Track                    [Page 2]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................6
      2.1. Requirements Language ......................................6
   3. Overview ........................................................6
      3.1. MAC Flushing on Activation of Backup Spoke PW ..............8
           3.1.1. MAC Flushing Initiated by PE-rs .....................8
           3.1.2. MAC Flushing Initiated by MTU-s .....................8
      3.2. MAC Flushing on Failure ....................................9
      3.3. MAC Flushing in PBB-VPLS ..................................10
   4. Problem Description ............................................10
      4.1. MAC Flushing Optimization in VPLS Resiliency ..............10
           4.1.1. MAC Flushing Optimization for Regular H-VPLS .......11
           4.1.2. MAC Flushing Optimization for Native Ethernet
                  Access .............................................13
      4.2. Black-Holing Issue in PBB-VPLS ............................13
   5. Solution Description ...........................................14
      5.1. MAC Flushing Optimization for VPLS Resiliency .............14
           5.1.1. MAC Flush Parameters TLV ...........................15
           5.1.2. Application of the MAC Flush TLV in
                  Optimized MAC Flushing .............................16
           5.1.3. MAC Flush TLV Processing Rules for Regular VPLS ....17
           5.1.4. Optimized MAC Flush Procedures .....................18
      5.2. LDP MAC Flush Extensions for PBB-VPLS .....................19
           5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS ........20
           5.2.2. Applicability of the MAC Flush Parameters TLV ......22
   6. Operational Considerations .....................................23
   7. IANA Considerations ............................................24
      7.1. New LDP TLV ...............................................24
      7.2. New Registry for MAC Flush Flags ..........................24
   8. Security Considerations ........................................24
   9. Contributing Author ............................................25
   10. Acknowledgements ..............................................25
   11. References ....................................................25
      11.1. Normative References .....................................25
      11.2. Informative References ...................................25














Dutta, et al.                Standards Track                    [Page 3]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


1.  Introduction

   A method of Virtual Private LAN Service (VPLS), also known as
   Transparent LAN Services (TLS), is described in [RFC4762].  A VPLS is
   created using a collection of one or more point-to-point pseudowires
   (PWs) [RFC4664] configured in a flat, full-mesh topology.  The mesh
   topology provides a LAN segment or broadcast domain that is fully
   capable of learning and forwarding on Ethernet Media Access Control
   (MAC) addresses at the Provider Edge (PE) devices.

   This VPLS full-mesh core configuration can be augmented with
   additional non-meshed spoke nodes to provide a Hierarchical VPLS
   (H-VPLS) service [RFC4762].  Throughout this document, this
   configuration is referred to as "regular" H-VPLS.

   [RFC7041] describes how Provider Backbone Bridging (PBB) can be
   integrated with VPLS to allow for useful PBB capabilities while
   continuing to avoid the use of the Multiple Spanning Tree Protocol
   (MSTP) in the backbone.  The combined solution, referred to as
   "PBB-VPLS", results in better scalability in terms of number of
   service instances, PWs, and C-MAC (Customer MAC) addresses that need
   to be handled in the VPLS PEs, depending on the location of the
   I-component in the PBB-VPLS topology.

   A MAC address withdrawal mechanism for VPLS is described in [RFC4762]
   to remove or unlearn MAC addresses for faster convergence on topology
   changes in resilient H-VPLS topologies.  Note that the H-VPLS
   topology discussed in [RFC4762] describes the two-tier hierarchy in
   VPLS as the basic building block of H-VPLS, but it is possible to
   have a multi-tier hierarchy in an H-VPLS.





















Dutta, et al.                Standards Track                    [Page 4]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   Figure 1 is reproduced from [RFC4762] and illustrates dual-homing
   in H-VPLS.

                                                            PE2-rs
                                                          +--------+
                                                          |        |
                                                          |   --   |
                                                          |  /  \  |
      CE-1                                                |  \S /  |
        \                                                 |   --   |
         \                                                +--------+
          \  MTU-s                          PE1-rs        /   |
          +--------+                      +--------+     /    |
          |        |                      |        |    /     |
          |   --   |   Primary PW         |   --   |---/      |
          |  /  \  |- - - - - - - - - - - |  /  \  |          |
          |  \S /  |                      |  \S /  |          |
          |   --   |                      |   --   |---\      |
          +--------+                      +--------+    \     |
            /      \                                     \    |
           /        \                                     +--------+
          /          \                                    |        |
         CE-2         \                                   |  --    |
                       \     Secondary PW                 | /  \   |
                        - - - - - - - - - - - - - - - - - | \S /   |
                                                          |  --    |
                                                          +--------+
                                                            PE3-rs

                Figure 1: An Example of a Dual-Homed MTU-s

   An example usage of the MAC flushing mechanism is the dual-homed
   H-VPLS where an edge device called the Multi-Tenant Unit switch
   (MTU-s) [RFC4762] is connected to two PE devices via a primary spoke
   PW and backup spoke PW, respectively.  Such redundancy is designed to
   protect against the failure of the primary spoke PW or primary PE
   device.  There could be multiple methods of dual-homing in H-VPLS
   that are not described in [RFC4762].  For example, note the following
   statement from Section 10.2.1 of [RFC4762].

      How a spoke is designated primary or secondary is outside the
      scope of this document.  For example, a spanning tree instance
      running between only the MTU-s and the two PE-rs nodes is one
      possible method.  Another method could be configuration.

   This document intends to clarify several H-VPLS dual-homing models
   that are deployed in practice and various use cases of LDP-based MAC
   flushing in these models.



Dutta, et al.                Standards Track                    [Page 5]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


2.  Terminology

   This document uses the terminology defined in [RFC7041], [RFC5036],
   [RFC4447], and [RFC4762].

   Throughout this document, "Virtual Private LAN Service" (VPLS) refers
   to the emulated bridged LAN service offered to a customer.  "H-VPLS"
   refers to the hierarchical connectivity or layout of the MTU-s and
   the Provider Edge routing- and switching-capable (PE-rs) devices
   offering the VPLS [RFC4762].

   The terms "spoke node" and "MTU-s" in H-VPLS are used
   interchangeably.

   "Spoke PW" refers to the Pseudowire (PW) that provides connectivity
   between MTU-s and PE-rs nodes.

   "Mesh PW" refers to the PW that provides connectivity between PE-rs
   nodes in a VPLS full-mesh core.

   "MAC flush message" refers to a Label Distribution Protocol (LDP)
   address withdraw message without a MAC List TLV.

   A MAC flush message "in the context of a PW" refers to the message
   that has been received over the LDP session that is used to set up
   the PW used to provide connectivity in VPLS.  The MAC flush message
   carries the context of the PW in terms of the Forwarding Equivalence
   Class (FEC) TLV associated with the PW [RFC4762] [RFC4447].

   In general, "MAC flushing" refers to the method of initiating and
   processing MAC flush messages across a VPLS instance.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Overview

   When the MTU-s switches over to the backup PW, the requirement is to
   flush the MAC addresses learned in the corresponding Virtual Switch
   Instance (VSI) in peer PE devices participating in the full mesh, to
   avoid the black-holing of frames to those addresses.  This is
   accomplished by sending an LDP address withdraw message -- a new
   message defined in this document -- from the PE that is no longer





Dutta, et al.                Standards Track                    [Page 6]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   connected to the MTU-s with the primary PW.  The new message contains
   a list of MAC addresses to be removed and is sent to all other PEs
   over the corresponding LDP sessions.

   In order to minimize the impact on LDP convergence time and
   scalability when a MAC List TLV contains a large number of MAC
   addresses, many implementations use an LDP address withdraw message
   with an empty MAC list.  When a PE-rs switch in the full mesh of
   H-VPLS receives this message, it also flushes MAC addresses that are
   not affected due to the topology change, thus leading to unnecessary
   flooding and relearning.  Throughout this document, the term "MAC
   flush message" is used to specify an LDP address withdraw message
   with an empty MAC list as described in [RFC4762].  The solutions
   described in this document are applicable only to LDP address
   withdraw messages with empty MAC lists.

   In a VPLS topology, the core PWs remain active and learning happens
   on the PE-rs nodes.  However, when the VPLS topology changes, the
   PE-rs must relearn using MAC address withdrawal or flushing.  As per
   the MAC address withdrawal processing rules in [RFC4762], a PE
   device, on receiving a MAC flush message, removes all MAC addresses
   associated with the specified VPLS instance (as indicated in the FEC
   TLV) except the MAC addresses learned over the PW associated with
   this signaling session over which the message was received.
   Throughout this document, we use the terminology "positive" MAC
   flushing or "flush-all-but-mine" for this type of MAC flush message
   and its actions.

   This document introduces an optimized "negative" MAC flush message,
   described in Section 3.2, that can be configured to improve the
   response to topology changes in a number of Ethernet topologies where
   the Service Level Agreement (SLA) is dependent on minimal disruption
   and fast restoration of affected traffic.  This new message is used
   in the case of Provider Backbone Bridging (PBB) topologies to
   restrict the flushing to a set of service instances (I-SIDs).  It is
   also important to note that the MAC flush message described in
   [RFC4762], which is called "a positive MAC flush message" in this
   document, MUST always be handled for Backbone MACs (B-MACs) in cases
   where the core nodes change or fail.  In dual-homed or multi-homed
   edge topologies, the procedures in this document augment [RFC4762]
   messages and provide less disruption for those cases.










Dutta, et al.                Standards Track                    [Page 7]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


3.1.  MAC Flushing on Activation of Backup Spoke PW

   This section describes scenarios where MAC flush withdrawal is
   initiated on activation of a backup PW in H-VPLS.

3.1.1.  MAC Flushing Initiated by PE-rs

   [RFC4762] specifies that on failure of the primary PW it is PE3-rs
   (Figure 1) that initiates MAC flushing towards the core.  However,
   note that PE3-rs can initiate MAC flushing only when PE3-rs is
   dual-homing "aware" -- that is, there is some redundancy management
   protocol running between the MTU-s and its host PE-rs devices.  The
   scope of this document is applicable to several dual-homing or
   multi-homing protocols.  This document illustrates that multi-homing
   can be improved with negative MAC flushing.  One example is BGP-based
   multi-homing in LDP-based VPLS, which uses the procedures defined in
   [VPLS-MH].  In this method of dual-homing, PE3-rs would neither
   forward any traffic to the MTU-s nor receive any traffic from the
   MTU-s while PE1-rs is acting as a primary (or designated forwarder).

3.1.2.  MAC Flushing Initiated by MTU-s

   When dual-homing is achieved by manual configuration in the MTU-s,
   the hosting PE-rs devices are dual-homing "agnostic", and PE3-rs
   cannot initiate MAC flush messages.  PE3-rs can send or receive
   traffic over the backup PW, since the dual-homing control is with the
   MTU-s only.  When the backup PW is made active by the MTU-s, the
   MTU-s triggers a MAC flush message.  The message is sent over the LDP
   session associated with the newly activated PW.  On receiving the MAC
   flush message from the MTU-s, PE3-rs (the PE-rs device with a
   now-active PW) would flush all the MAC addresses it has learned,
   except the ones learned over the newly activated spoke PW.  PE3-rs
   further initiates a MAC flush message to all other PE devices in the
   core.  Note that a forced switchover to the backup PW can also be
   invoked by the MTU-s due to maintenance or administrative activities
   on the former primary spoke PW.

   The method of MAC flushing initiated by the MTU-s is modeled after
   Topology Change Notification (TCN) in the Rapid Spanning Tree
   Protocol (RSTP) [IEEE.802.1Q-2011].  When a bridge switches from a
   failed link to the backup link, the bridge sends out a TCN message
   over the newly activated link.  Upon receiving this message, the
   upstream bridge flushes its entire list of MAC addresses, except the
   ones received over this link.  The upstream bridge then sends the TCN
   message out of its other ports in that spanning tree instance.  The
   message is further relayed along the spanning tree by the other
   bridges.




Dutta, et al.                Standards Track                    [Page 8]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   The MAC flushing information is propagated in the control plane.  The
   control-plane message propagation is associated with the data path
   and hence follows propagation rules similar to those used for
   forwarding in the LDP data plane.  For example, PE-rs nodes follow
   the data-plane "split-horizon" forwarding rules in H-VPLS (refer to
   Section 4.4 of [RFC4762]).  Therefore, a MAC flush message is
   propagated in the context of mesh PW(s) when it is received in the
   context of a spoke PW.  When a PE-rs node receives a MAC flush
   message in the context of a mesh PW, then it is not propagated to
   other mesh PWs.

3.2.  MAC Flushing on Failure

   MAC flushing on failure, or "negative" MAC flushing, is introduced in
   this document.  Negative MAC flushing is an improvement on the
   current practice of sending a MAC flush message with an empty MAC
   list as described in Section 3.1.1.  We use the term "negative" MAC
   flushing or "flush-all-from-me" for this kind of flushing action as
   opposed to the "positive" MAC flush action in [RFC4762].  In negative
   MAC flushing, the MAC flushing is initiated by PE1-rs (Figure 1) on
   detection of failure of the primary spoke PW.  The MAC flush message
   is sent to all participating PE-rs devices in the VPLS full mesh.
   PE1-rs should initiate MAC flushing only if PE1-rs is dual-homing
   aware.  (If PE1-rs is dual-homing agnostic, the policy is to not
   initiate MAC flushing on failure, since that could cause unnecessary
   flushing in the case of a single-homed MTU-s.)  The specific dual-
   homing protocols for this scenario are outside the scope of this
   document, but the operator can choose to use the optimized MAC
   flushing described in this document or the [RFC4762] procedures.

   The procedure for negative MAC flushing is beneficial and results in
   less disruption than the [RFC4762] procedures, including when the
   MTU-s is dual-homed with a variety of Ethernet technologies, not just
   LDP.  The negative MAC flush message is a more targeted MAC flush,
   and the other PE-rs nodes will flush only the specified MACs.  This
   targeted MAC flush cannot be achieved with the MAC address withdraw
   message defined in [RFC4762].  Negative MAC flushing typically
   results in a smaller set of MACs to be flushed and results in less
   disruption for these topologies.

   Note that in the case of negative MAC flushing the list SHOULD be
   only the MACs for the affected MTU-s.  If the list is empty, then the
   negative MAC flush procedures will result in flushing and relearning
   all attached MTU-s devices for the originating PE-rs.







Dutta, et al.                Standards Track                    [Page 9]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


3.3.  MAC Flushing in PBB-VPLS

   [RFC7041] describes how PBB can be integrated with VPLS to allow for
   useful PBB capabilities while continuing to avoid the use of MSTP in
   the backbone.  The combined solution, referred to as "PBB-VPLS",
   results in better scalability in terms of the number of service
   instances, PWs, and C-MACs that need to be handled in the VPLS PE-rs
   devices.  This document describes extensions to LDP MAC flushing
   procedures described in [RFC4762] that are required to build
   desirable capabilities for the PBB-VPLS solution.

   The solution proposed in this document is generic and is applicable
   when Multi-Segment Pseudowires (MS-PWs) [RFC6073] are used in
   interconnecting PE devices in H-VPLS.  There could be other H-VPLS
   models not defined in this document where the solution may be
   applicable.

4.  Problem Description

   This section describes the problems in detail with respect to various
   MAC flushing actions described in Section 3.

4.1.  MAC Flushing Optimization in VPLS Resiliency

   This section describes the optimizations required in MAC flushing
   procedures when H-VPLS resiliency is provided by primary and backup
   spoke PWs.
























Dutta, et al.                Standards Track                   [Page 10]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


4.1.1.  MAC Flushing Optimization for Regular H-VPLS

   Figure 2 shows a dual-homed H-VPLS scenario for a VPLS instance,
   where the problem with the existing MAC flushing method is as
   explained in Section 3.

                                 PE1-rs                       PE3-rs
                               +--------+                  +--------+
                               |        |                  |        |
                               |   --   |                  |   --   |
   Customer Site 1             |  /  \  |------------------|  /  \  |->Z
   X->CE-1               /-----|  \s /  |                  |  \s /  |
       \     primary spoke PW  |   --   |           /------|   --   |
        \             /        +--------+          /       +--------+
         \    (MTU-s)/              |    \        /             |
          +--------+/               |     \      /              |
          |        |                |      \    /               |
          |   --   |                |       \  /                |
          |  /  \  |                |      H-VPLS Full-Mesh Core|
          |  \s /  |                |       / \                 |
          |   --   |                |      /   \                |
         /+--------+\               |     /     \               |
        /     backup spoke PW       |    /       \              |
       /              \        +--------+         \--------+--------+
   Y->CE-2             \       |        |                  |        |
   Customer Site 2      \------|  --    |                  |  --    |
                               | /  \   |------------------| /  \   |->
                               | \s /   |                  | \s /   |
                               |  --    |                  |  --    |
                               +--------+                  +--------+
                                 PE2-rs                      PE4-rs

          Figure 2: Dual-Homed MTU-s in Two-Tier Hierarchy H-VPLS

   In Figure 2, the MTU-s is dual-homed to PE1-rs and PE2-rs.  Only the
   primary spoke PW is active at the MTU-s; thus, PE1-rs is acting as
   the active device (designated forwarder) to reach the full mesh in
   the VPLS instance.  The MAC addresses of nodes located at access
   sites (behind CE-1 and CE-2) are learned at PE1-rs over the primary
   spoke PW.  Let's say X represents a set of such MAC addresses located
   behind CE-1.  MAC Z represents one of a possible set of other
   destination MACs.  As packets flow from X to other MACs in the VPLS
   network, PE2-rs, PE3-rs, and PE4-rs learn about X on their respective
   mesh PWs terminating at PE1-rs.  When the MTU-s switches to the
   backup spoke PW and activates it, PE2-rs becomes the active device
   (designated forwarder) to reach the full-mesh core for the MTU-s.
   Traffic entering the H-VPLS from CE-1 and CE-2 is diverted by the
   MTU-s to the spoke PW to PE2-rs.  Traffic destined from PE2-rs,



Dutta, et al.                Standards Track                   [Page 11]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   PE3-rs, and PE4-rs to X will be black-holed until the MAC address
   aging timer expires (the default is 5 minutes) or a packet flows from
   X to other addresses through PE2-rs.

   For example, if a packet flows from MAC Z to MAC X after the backup
   spoke PW is active, packets from MAC Z travel from PE3-rs to PE1-rs
   and are dropped.  However, if a packet with MAC X as source and MAC Z
   as destination arrives at PE2-rs, PE2-rs will now learn that MAC X is
   on the backup spoke PW and will forward to MAC Z.  At this point,
   traffic from PE3-rs to MAC X will go to PE2-rs, since PE3-rs has also
   learned about MAC X.  Therefore, a mechanism is required to make this
   learning more timely in cases where traffic is not bidirectional.

   To avoid traffic black-holing, the MAC addresses that have been
   learned in the upstream VPLS full mesh through PE1-rs must be
   relearned or removed from the MAC Forwarding Information Bases (FIBs)
   in the VSIs at PE2-rs, PE3-rs, and PE4-rs.  If PE1-rs and PE2-rs are
   dual-homing agnostic, then on activation of the standby PW from the
   MTU-s, a MAC flush message will be sent by the MTU-s to PE2-rs that
   will flush all the MAC addresses learned in the VPLS instance at
   PE2-rs from all other PWs except the PW connected to the MTU-s.

   PE2-rs further relays the MAC flush messages to all other PE-rs
   devices in the full mesh.  The same processing rule applies for all
   those PE-rs devices: all the MAC addresses are flushed except the
   ones learned on the PW connected to PE2-rs.  For example, at PE3-rs
   all of the MAC addresses learned from the PWs connected to PE1-rs and
   PE4-rs are flushed and relearned subsequently.  Before the relearning
   happens, flooding of unknown destination MAC addresses takes place
   throughout the network.  As the number of PE-rs devices in the full
   mesh increases, the number of unaffected MAC addresses flushed in a
   VPLS instance also increases, thus leading to unnecessary flooding
   and relearning.  With a large number of VPLS instances provisioned in
   the H-VPLS network topology, the amount of unnecessary flooding and
   relearning increases.  An optimization, described below, is required
   that will flush only the MAC addresses learned from the respective
   PWs between PE1-rs and other PE devices in the full mesh, to minimize
   the relearning and flooding in the network.  In the example above,
   only the MAC addresses in sets X and Y (shown in Figure 2) need to be
   flushed across the core.

   The same case is applicable when PE1-rs and PE2-rs are dual-homing
   aware and participate in a designated forwarder election.  When
   PE2-rs becomes the active device for the MTU-s, then PE2-rs MAY
   initiate MAC flushing towards the core.  The receiving action of the
   MAC flush message in other PE-rs devices is the same as in MAC
   flushing initiated by the MTU-s.  This is the behavior specified in
   [RFC4762].



Dutta, et al.                Standards Track                   [Page 12]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


4.1.2.  MAC Flushing Optimization for Native Ethernet Access

   The analysis in Section 4.1.1 applies also to the native Ethernet
   access into a VPLS.  In such a scenario, one active endpoint and one
   or more standby endpoints terminate into two or more VPLS or H-VPLS
   PE-rs devices.  Examples of this dual-homed access are ITU-T
   [ITU.G8032] access rings or any proprietary multi-chassis Link
   Aggregation Group (LAG) emulations.  Upon failure of the active
   native Ethernet endpoint on PE1-rs, an optimized MAC flush message is
   required to be initiated by PE1-rs to ensure that on PE2-rs, PE3-rs,
   and PE4-rs only the MAC addresses learned from the respective PWs
   connected to PE1-rs are being flushed.

4.2.  Black-Holing Issue in PBB-VPLS

   In a PBB-VPLS deployment, a B-component VPLS (B-VPLS) may be used as
   infrastructure to support one or more I-component instances.  The
   B-VPLS control plane (LDP Signaling) and learning of Backbone MACs
   (B-MACs) replace the I-component control plane and learning of
   Customer MACs (C-MACs) throughout the MPLS core.  This raises an
   additional challenge related to black-hole avoidance in the
   I-component domain as described in this section.  Figure 3 describes
   the case of a Customer Edge (CE) device (node A) dual-homed to two
   I-component instances located on two PBB-VPLS PEs (PE1-rs and
   PE2-rs).

                              IP/MPLS Core
                            +--------------+
                            |PE2-rs        |
                           +----+          |
                           |PBB |          |
                           |VPLS|   +-+    |
                           |(B2)|---|P|    |
                      Stby/+----+  /+-+\   |PE3-rs
                         / +----+ /     \+----+
                   +---+/  |PBB |/  +-+  |PBB |   +---+
          C-MAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--C-MAC Y
                   |   |Act|(B1)|   +-+  |    |   |   |
                   +---+   +----+        +----+   +---+
                     A      |PE1-rs        |        B
                            |              |
                            +--------------+

        Figure 3: PBB Black-Holing Issue - CE Dual-Homing Use Case

   The link between PE1-rs and CE-A is active (marked with A), while the
   link between CE-A and PE2-rs is in standby/blocked status.  In the
   network diagram, C-MAC X is one of the MAC addresses located behind



Dutta, et al.                Standards Track                   [Page 13]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   CE-A in the customer domain, C-MAC Y is behind CE-B, and the B-VPLS
   instances on PE1-rs are associated with B-MAC B1 and PE2-rs with
   B-MAC B2.

   As the packets flow from C-MAC X to C-MAC Y through PE1-rs with
   B-MAC B1, the remote PE-rs devices participating in the B-VPLS with
   the same I-SID (for example, PE3-rs) will learn the C-MAC X
   associated with B-MAC B1 on PE1-rs.  Under a failure condition of the
   link between CE-A and PE1-rs and on activation of the link to PE2-rs,
   the remote PE-rs devices (for example, PE3-rs) will forward the
   traffic destined for C-MAC X to B-MAC B1, resulting in PE1-rs black-
   holing that traffic until the aging timer expires or a packet flows
   from X to Y through PE2-rs (B-MAC B2).  This may take a long time
   (the default aging timer is 5 minutes) and may affect a large number
   of flows across multiple I-components.

   A possible solution to this issue is to use the existing LDP MAC
   flushing method as specified in [RFC4762] to flush the B-MAC
   associated with the PE-rs in the B-VPLS domain where the failure
   occurred.  This will automatically flush the C-MAC-to-B-MAC
   association in the remote PE-rs devices.  This solution has the
   disadvantage of producing a lot of unnecessary MAC flushing in the
   B-VPLS domain as there was no failure or topology change affecting
   the Backbone domain.

   A better solution -- one that would propagate the I-component events
   through the backbone infrastructure (B-VPLS) -- is required in order
   to flush only the C-MAC-to-B-MAC associations in the remote PBB-VPLS-
   capable PE-rs devices.  Since there are no I-component control-plane
   exchanges across the PBB backbone, extensions to the B-VPLS control
   plane are required to propagate the I-component MAC flushing events
   across the B-VPLS.

5.  Solution Description

   This section describes the solution for the problem space described
   in Section 4.

5.1.  MAC Flushing Optimization for VPLS Resiliency

   The basic principle of the optimized MAC flush mechanism is explained
   with reference to Figure 2.  The optimization is achieved by
   initiating MAC flushing on failure as described in Section 3.2.

   PE1-rs would initiate MAC flushing towards the core on detection of
   failure of the primary spoke PW between the MTU-s and PE1-rs (or
   status change from active to standby [RFC6718]).  This method is
   referred to as "MAC flushing on failure" throughout this document.



Dutta, et al.                Standards Track                   [Page 14]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   The MAC flush message would indicate to receiving PE-rs devices to
   flush all MACs learned over the PW in the context of the VPLS for
   which the MAC flush message is received.  Each PE-rs device in the
   full mesh that receives the message identifies the VPLS instance and
   its respective PW that terminates in PE1-rs from the FEC TLV received
   in the message and/or LDP session.  Thus, the PE-rs device flushes
   only the MAC addresses learned from that PW connected to PE1-rs,
   minimizing the required relearning and the flooding throughout the
   VPLS domain.

   This section defines a generic MAC Flush Parameters TLV for LDP
   [RFC5036].  Throughout this document, the MAC Flush Parameters TLV is
   also referred to as the "MAC Flush TLV".  A MAC Flush TLV carries
   information on the desired action at the PE-rs device receiving the
   message and is used for optimized MAC flushing in VPLS.  The MAC
   Flush TLV can also be used for the [RFC4762] style of MAC flushing as
   explained in Section 3.

5.1.1.  MAC Flush Parameters TLV

   The MAC Flush Parameters TLV is described below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1|  MAC Flush TLV (0x0406)   |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     | Sub-TLV Type  |         Sub-TLV Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Sub-TLV Variable-Length Value                  |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The U-bit and F-bit [RFC5036] are set to forward if unknown so that
   potential intermediate VPLS PE-rs devices unaware of the new TLV can
   just propagate it transparently.  In the case of a B-VPLS network
   that has PBB-VPLS in the core with no I-components attached, this
   message can still be useful to edge B-VPLS devices that do have the
   I-components with the I-SIDs and understand the message.  The MAC
   Flush Parameters TLV type is 0x0406, as assigned by IANA.  The
   encoding of the TLV follows the standard LDP TLV encoding described
   in [RFC5036].

   The TLV value field contains a 1-byte Flag field used as described
   below.  Further, the TLV value MAY carry one or more sub-TLVs.  Any
   sub-TLV definition for the above TLV MUST address the actions in
   combination with other existing sub-TLVs.




Dutta, et al.                Standards Track                   [Page 15]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   The detailed format for the Flags bit vector is described below:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |C|N|    MBZ    | (MBZ = MUST Be Zero)
      +-+-+-+-+-+-+-+-+

      The 1-byte Flag field is mandatory.  The following flags are
      defined:

      C-flag: Used to indicate the context of the PBB-VPLS component in
         which MAC flushing is required.  For PBB-VPLS, there are two
         contexts of MAC flushing -- the Backbone VPLS (B-component
         VPLS) and the Customer VPLS (I-component VPLS).  The C-flag
         MUST be ZERO (C = 0) when a MAC flush action for the B-VPLS is
         required and MUST be set (C = 1) when the MAC flush action for
         the I-component is required.  In the regular H-VPLS case, the
         C-flag MUST be ZERO (C = 0) to indicate that the flush applies
         to the current VPLS context.

      N-flag: Used to indicate whether a positive (N = 0,
         flush-all-but-mine) or negative (N = 1, flush-all-from-me) MAC
         flush action is required.  The source (mine/me) is defined as
         the PW associated with either the LDP session on which the LDP
         MAC withdraw was received or the B-MAC(s) listed in the B-MAC
         Sub-TLV.  For the optimized MAC flush procedure described in
         this section, the flag MUST be set (N = 1).

      Detailed usage in the context of PBB-VPLS is explained in
      Section 5.2.

      MBZ flags: The rest of the flags SHOULD be set to zero on
         transmission and ignored on reception.

      The MAC Flush TLV SHOULD be placed after the existing TLVs in the
      [RFC4762] MAC flush message.

5.1.2.  Application of the MAC Flush TLV in Optimized MAC Flushing

   When optimized MAC flushing is supported, the MAC Flush TLV MUST be
   sent in an existing LDP address withdraw message with an empty MAC
   list but from the core PE-rs on detection of failure of its
   local/primary spoke PW.  The N-bit in the TLV MUST be set to 1 to
   indicate flush-all-from-me.  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 it is used in an I-component context, the
   C-bit MUST be set (C = 1).  See Section 5.2 for details of its usage
   in the context of PBB-VPLS.



Dutta, et al.                Standards Track                   [Page 16]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   Note that the assumption is that the MAC Flush TLV is understood by
   all devices before it is turned on in any network.  See Section 6
   ("Operational Considerations").

   When optimized MAC flushing is not supported, the MAC withdraw
   procedures defined in [RFC4762], where either the MTU-s or PE2-rs
   sends the MAC withdraw message, SHOULD be used.  This includes the
   case where the network is being changed to support optimized MAC
   flushing but not all devices are capable of understanding optimized
   MAC flush messages.

   In the case of B-VPLS devices, the optimized MAC flush message SHOULD
   be supported.

5.1.3.  MAC Flush TLV Processing Rules for Regular VPLS

   This section describes the processing rules of the MAC Flush TLV that
   MUST be followed in the context of optimized MAC flush procedures
   in VPLS.

   When optimized MAC flushing is supported, a multi-homing PE-rs
   initiates a MAC flush message towards the other related VPLS PE-rs
   devices when it detects a transition (failure or a change to standby)
   in its active spoke PW.  In such a case the MAC Flush TLV MUST be
   sent with N = 1.  A PE-rs device receiving the MAC Flush TLV SHOULD
   follow the same processing rules as those described in this section.

   Note that if a Multi-Segment Pseudowire (MS-PW) is used in VPLS, then
   a MAC flush message is processed only at the PW Terminating Provider
   Edge (T-PE) nodes, since PW Switching Provider Edge S-PE(s) traversed
   by the MS-PW propagates the MAC flush messages without any action.
   In this section, a PE-rs device signifies only a T-PE in the MS-PW
   case.

   When a PE-rs device receives a MAC Flush TLV with N = 1, it SHOULD
   flush all the MAC addresses learned from the PW in the VPLS in the
   context on which the MAC flush message is received.  It is assumed
   that when these procedures are used all nodes support the MAC flush
   message.  See Section 6 ("Operational Considerations") for details.

   When optimized MAC flushing is not supported, a MAC Flush TLV is
   received with N = 0 in the MAC flush message; in such a case, the
   receiving PE-rs SHOULD flush the MAC addresses learned from all PWs
   in the VPLS instance, except the ones learned over the PW on which
   the message is received.






Dutta, et al.                Standards Track                   [Page 17]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   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 MAC address list, it SHOULD ignore the
   option and deal with MAC addresses explicitly as per [RFC4762].

5.1.4.  Optimized MAC Flush Procedures

   This section expands on the optimized MAC flush procedure in the
   scenario shown in Figure 2.

   When optimized MAC flushing is being used, a PE-rs that is dual-
   homing aware SHOULD send MAC address messages with a MAC Flush TLV
   and N = 1, provided the other PEs understand the new messages.  Upon
   receipt of the MAC flush message, PE2-rs identifies the VPLS instance
   that requires MAC flushing from the FEC element in the FEC TLV.  On
   receiving N = 1, PE2-rs removes all MAC addresses learned from that
   PW over which the message is received.  The same action is performed
   by PE3-rs and PE4-rs.

   Figure 4 shows another redundant H-VPLS topology to protect against
   failure of the MTU-s device.  In this case, since there is more than
   a single MTU-S, a protocol such as provider RSTP [IEEE.802.1Q-2011]
   may be used as the selection algorithm for active and backup PWs in
   order to maintain the connectivity between MTU-s devices and PE-rs
   devices at the edge.  It is assumed that PE-rs devices can detect
   failure on PWs in either direction through OAM mechanisms (for
   instance, Virtual Circuit Connectivity Verification (VCCV)
   procedures).

              MTU-1================PE1-rs==============PE3-rs
                ||                  || \             /||
                ||  Redundancy      ||  \           / ||
                ||  Provider RSTP   ||   Full Mesh .  ||
                ||                  ||  /           \ ||
                ||                  || /             \||
              MTU-2----------------PE2-rs==============PE4-rs
                     Backup PW

                  Figure 4: Redundancy with Provider RSTP

   MTU-1, MTU-2, PE1-rs, and PE2-rs participate in provider RSTP.
   Configuration using RSTP ensures that the PW between MTU-1 and PE1-rs
   is active and the PW between MTU-2 and PE2-rs is blocked (made
   backup) at the MTU-2 end.  When the active PW failure is detected by
   RSTP, it activates the PW between MTU-2 and PE2-rs.  When PE1-rs
   detects the failing PW to MTU-1, it MAY trigger MAC flushing into the
   full mesh with a MAC Flush TLV that carries N = 1.  Other PE-rs




Dutta, et al.                Standards Track                   [Page 18]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   devices in the full mesh that receive the MAC flush message identify
   their respective PWs terminating on PE1-rs and flush all the MAC
   addresses learned from it.

   [RFC4762] describes a multi-domain VPLS service where fully meshed
   VPLS networks (domains) are connected together by a single spoke PW
   per VPLS service between the VPLS "border" PE-rs devices.  To provide
   redundancy against failure of the inter-domain spoke, full mesh of
   inter-domain spokes can be set up between border PE-rs devices, and
   provider RSTP may be used for selection of the active inter-domain
   spoke.  In the case of inter-domain spoke PW failure, MAC withdrawal
   initiated by PE-rs MAY be used for optimized MAC flush procedures
   within individual domains.

   Further, the procedures are applicable to any native Ethernet access
   topologies multi-homed to two or more VPLS PE-rs devices.  The text
   in this section applies for the native Ethernet case where
   active/standby PWs are replaced with the active/standby Ethernet
   endpoints.  An optimized MAC flush message can be generated by the
   VPLS PE-rs that detects the failure in the primary Ethernet access.

5.2.  LDP MAC Flush Extensions for PBB-VPLS

   The use of an address withdraw message with a MAC List TLV is
   proposed in [RFC4762] as a way to expedite removal of MAC addresses
   as the result of a topology change (e.g., failure of a primary link
   of a VPLS PE-rs device and, implicitly, the activation of an
   alternate link in a dual-homing use case).  These existing procedures
   apply individually to B-VPLS and I-component domains.

   When it comes to reflecting topology changes in access networks
   connected to I-components across the B-VPLS domain, certain additions
   should be considered, as described below.

   MAC switching in PBB is based on the mapping of Customer MACs
   (C-MACs) to one or more Backbone MACs (B-MACs).  A topology change in
   the access (I-component domain) should just invoke the flushing of
   C-MAC entries in the PBB PEs' FIB(s) associated with the
   I-component(s) impacted by the failure.  There is a need to indicate
   the PBB PE (B-MAC source) that originated the MAC flush message to
   selectively flush only the MACs that are affected.

   These goals can be achieved by including the MAC Flush Parameters TLV
   in the LDP address withdraw message to indicate the particular
   domain(s) requiring MAC flushing.  On the other end, the receiving
   PEs SHOULD use the information from the new TLV to flush only the
   related FIB entry/entries in the I-component instance(s).




Dutta, et al.                Standards Track                   [Page 19]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   At least one of the following sub-TLVs MUST be included in the MAC
   Flush Parameters TLV if the C-flag is set to 1:

   o  PBB B-MAC List Sub-TLV:

      Type: 0x0407

      Length: Value length in octets.  At least one B-MAC address MUST
      be present in the list.

      Value: One or a list of 48-bit B-MAC addresses.  These are the
      source B-MAC addresses associated with the B-VPLS instance that
      originated the MAC withdraw message.  It will be used to identify
      the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV.

   o  PBB I-SID List Sub-TLV:

      Type: 0x0408

      Length: Value length in octets.  Zero indicates an empty I-SID
      list.  An empty I-SID list means that the flushing applies to all
      the I-SIDs mapped to the B-VPLS indicated by the FEC TLV.

      Value: One or a list of 24-bit I-SIDs that represent the
      I-component FIB(s) where the MAC flushing needs to take place.

5.2.1.  MAC Flush TLV Processing Rules for PBB-VPLS

   The following steps describe the details of the processing rules for
   the MAC Flush TLV in the context of PBB-VPLS.  In general, these
   procedures are similar to the VPLS case but are tailored to PBB,
   which may have a large number of MAC addresses.  In PBB, there are
   two sets of MAC addresses: Backbone (outer) MACs (B-MACs) and
   Customer (inner) MACs (C-MACs).  C-MACs are associated to remote
   B-MACs by learning.  There are also I-SIDs in PBB; I-SIDs are similar
   to VLANs for the purposes of the discussion in this section.  In
   order to achieve behavior that is similar to the Regular VPLS case,
   there are some differences in the interpretation of the optimized MAC
   flush message.

   1. Positive flush of C-MACs.  This is equivalent to [RFC4762] MAC
      flushing in a PBB context.  In this case, the N-bit is set to 0;
      the C-bit is set to 1, and C-MACs are to be flushed.  However,
      since C-MACs are related to B-MACs in an I-SID context, further
      refinement of the flushing scope is possible.






Dutta, et al.                Standards Track                   [Page 20]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


      - If an I-SID needs to be flushed (all C-MACs within that I-SID),
        then I-SIDs are listed in the appropriate TLV.  If all I-SIDs
        are to have the C-MACs flushed, then the I-SID TLV can be empty.
        It is typical to flush a single I-SID only, since each I-SID is
        associated with one or more interfaces (typically one, in the
        case of dual-homing).  In the PBB case, flushing the I-SID is
        equivalent to the empty MAC list discussed in [RFC4762].

      - If only a set of B-MAC-to-C-MAC associations needs to be
        flushed, then a B-MAC list can be included to further refine the
        list.  This can be the case if an I-SID component has more than
        one interface and a B-MAC is used to refine the granularity.
        Since this is a positive MAC flush message, the intended
        behavior is to flush all C-MACs except those that are associated
        with B-MACs in the list.

        Positive flush of B-MACs is also useful for propagating flush
        from other protocols such as RSTP.

   2. Negative flush of C-MACs.  This is equivalent to optimized MAC
      flushing.  In this case, the N-bit is set to 1; the C-bit is set
      to 1, and a list of B-MACs is provided so that the respective
      C-MACs can be flushed.

      - The I-SID list SHOULD be specified.  If it is absent, then all
        I-SIDs require that the C-MACs be flushed.

      - A set of B-MACs SHOULD be listed, since B-MAC-to-C-MAC
        associations need to be flushed and listing B-MACs scopes the
        flush to just those B-MACs.  Again, this is typical usage,
        because a PBB VPLS I-component interface will have one
        associated I-SID and typically one (but possibly more than one)
        B-MAC, each with multiple remotely learned C-MACs.  The B-MAC
        list is included to further refine the list for the remote
        receiver.  Since this is a negative MAC flush message, the
        intended behavior is to flush all remote C-MACs that are
        associated with any B-MACs in the list (in other words, from the
        affected interface).

   The processing rules on reception of the MAC flush message are:

   - On Backbone Core Bridges (BCBs), if the C-bit is set to 1, then the
     PBB-VPLS SHOULD NOT flush their B-MAC FIBs.  The B-VPLS control
     plane SHOULD propagate the MAC flush message following the data-
     plane split-horizon rules to the established B-VPLS topology.






Dutta, et al.                Standards Track                   [Page 21]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   - On Backbone Edge Bridges (BEBs), the following actions apply:

      - The PBB I-SID list is used to determine the particular I-SID
        FIBs (I-component) that need to be considered for flushing
        action.  If the PBB I-SID List Sub-TLV is not included in a
        received message, then all the I-SID FIBs associated with the
        receiving B-VPLS SHOULD be considered for flushing action.

      - The PBB B-MAC list is used to identify from the I-SID FIBs in
        the previous step to selectively flush B-MAC-to-C-MAC
        associations, depending on the N-flag specified below.  If the
        PBB B-MAC List Sub-TLV is not included in a received message,
        then all B-MAC-to-C-MAC associations in all I-SID FIBs
        (I-component) as specified by the I-SID List are considered for
        required flushing action, again depending on the N-flag
        specified below.

      - Next, depending on the N-flag value, the following actions
        apply:

        - N = 0: all the C-MACs in the selected I-SID FIBs SHOULD be
          flushed, with the exception of the resultant C-MAC list from
          the B-MAC list mentioned in the message ("flush all but the
          C-MACs associated with the B-MAC(s) in the B-MAC List Sub-TLV
          from the FIBs associated with the I-SID list").

        - N = 1: all the resultant C-MACs SHOULD be flushed ("flush all
          the C-MACs associated with the B-MAC(s) in the B-MAC List
          Sub-TLV from the FIBs associated with the I-SID list").

5.2.2.  Applicability of the MAC Flush Parameters TLV

   If the MAC Flush Parameters TLV is received by a Backbone Edge Bridge
   (BEB) in a PBB-VPLS that does not understand the TLV, then an
   undesirable MAC flushing action may result.  It is RECOMMENDED that
   all PE-rs devices participating in PBB-VPLS support the MAC Flush
   Parameters TLV.  If this is not possible, the MAC Flush Parameters
   TLV SHOULD be disabled, as mentioned in Section 6 ("Operational
   Considerations").

   "Mac Flush TLV" and its formal name -- "MAC Flush Parameters TLV" --
   are synonymous.  The MAC Flush TLV is applicable to the regular VPLS
   context as well, as explained in Section 3.1.1.  To achieve negative
   MAC flushing (flush-all-from-me) in a regular VPLS context, the MAC
   Flush Parameters TLV SHOULD be encoded with C = 0 and N = 1 without






Dutta, et al.                Standards Track                   [Page 22]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   inclusion of any Sub-TLVs.  A negative MAC flush message is highly
   desirable in scenarios where VPLS access redundancy is provided by
   Ethernet ring protection as specified in the ITU-T G.8032 [ITU.G8032]
   specification.

6.  Operational Considerations

   As mentioned earlier, if the MAC Flush Parameters TLV is not
   understood by a receiver, then an undesirable MAC flushing action
   would result.  To avoid this, one possible solution is to develop an
   LDP-based capability negotiation mechanism to negotiate support of
   various MAC flushing capabilities between PE-rs devices in a VPLS
   instance.  A negotiation mechanism was discussed previously and was
   considered outside the scope of this document.  Negotiation is not
   required to deploy this optimized MAC flushing as described in this
   document.

   VPLS may be used with or without the optimization.  If an operator
   wants the optimization for VPLS, it is the operator's responsibility
   to make sure that the VPLS devices that are capable of supporting the
   optimization are properly configured.  From an operational
   standpoint, it is RECOMMENDED that implementations of the solution
   provide administrative control to select the desired MAC flushing
   action towards a PE-rs device in the VPLS.  Thus, in the topology
   described in Figure 2, an implementation could support PE1-rs,
   sending optimized MAC flush messages towards the PE-rs devices that
   support the solution and the PE2-rs device initiating the [RFC4762]
   style of MAC flush messages towards the PE-rs devices that do not
   support the optimized solution during upgrades.  The PE-rs that
   supports the MAC Flush Parameters TLV MUST support the RFC 4762 MAC
   flushing procedures, since this document only augments them.

   In the case of PBB-VPLS, this operation is the only method supported
   for specifying I-SIDs, and the optimization is assumed to be
   supported or should be turned off, reverting to flushing using
   [RFC4762] at the Backbone MAC level.















Dutta, et al.                Standards Track                   [Page 23]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


7.  IANA Considerations

7.1.  New LDP TLV

   IANA maintains a registry called "Label Distribution Protocol (LDP)
   Parameters" with a sub-registry called "TLV Type Name Space".

   IANA has allocated three new code points as follows:

       Value | Description               | Reference  | Notes
      -------+---------------------------+------------+-----------
      0x0406 | MAC Flush Parameters TLV  | [RFC7361]  |
      0x0407 | PBB B-MAC List Sub-TLV    | [RFC7361]  |
      0x0408 | PBB I-SID List Sub-TLV    | [RFC7361]  |

7.2.  New Registry for MAC Flush Flags

   IANA has created a new sub-registry under "Label Distribution
   Protocol (LDP) Parameters" called "MAC Flush Flags".

   IANA has populated the registry as follows:

   Bit Number | Hex  | Abbreviation | Description           | Reference
   -----------+------+--------------+-----------------------+-----------
     0        | 0x80 | C            | Context               | [RFC7361]
     1        | 0x40 | N            | Negative MAC flushing | [RFC7361]
     2-7      |      |              | Unassigned            |

   Other new bits are to be assigned by Standards Action [RFC5226].

8.  Security Considerations

   Control-plane aspects:

      LDP security (authentication) methods as described in [RFC5036]
      are applicable here.  Further, this document implements security
      considerations as discussed in [RFC4447] and [RFC4762].  The
      extensions defined here optimize the MAC flushing action, and so
      the risk of security attacks is reduced.  However, in the event
      that the configuration of support for the new TLV can be spoofed,
      sub-optimal behavior will be seen.

   Data-plane aspects:

      This specification does not have any impact on the VPLS forwarding
      plane but can improve MAC flushing behavior.





Dutta, et al.                Standards Track                   [Page 24]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


9.  Contributing Author

   The authors would like to thank Marc Lasserre, who made a major
   contribution to the development of this document.

      Marc Lasserre
      Alcatel-Lucent
      EMail: marc.lasserre@alcatel-lucent.com

10.  Acknowledgements

   The authors would like to thank the following people who have
   provided valuable comments, feedback, and review on the topics
   discussed in this document: Dimitri Papadimitriou, Jorge Rabadan,
   Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim
   Henderickx, Paul Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar,
   Giles Heron, Adrian Farrel, Ben Niven-Jenkins, Robert Sparks, Susan
   Hares, and Stephen Farrell.

11.  References

11.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4447]   Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
               G. Heron, "Pseudowire Setup and Maintenance Using the
               Label Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC4762]   Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
               LAN Service (VPLS) Using Label Distribution Protocol
               (LDP) Signaling", RFC 4762, January 2007.

   [RFC5036]   Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
               "LDP Specification", RFC 5036, October 2007.

11.2.  Informative References

   [IEEE.802.1Q-2011]
               IEEE, "IEEE Standard for Local and metropolitan area
               networks -- Media Access Control (MAC) Bridges and
               Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
               2011.

   [ITU.G8032] International Telecommunication Union, "Ethernet ring
               protection switching", ITU-T Recommendation G.8032,
               February 2012.



Dutta, et al.                Standards Track                   [Page 25]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


   [RFC4664]   Andersson, L., Ed., and E. Rosen, Ed., "Framework for
               Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
               September 2006.

   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

   [RFC6073]   Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
               Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

   [RFC6718]   Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
               Redundancy", RFC 6718, August 2012.

   [RFC7041]   Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
               "Extensions to the Virtual Private LAN Service (VPLS)
               Provider Edge (PE) Model for Provider Backbone Bridging",
               RFC 7041, November 2013.

   [VPLS-MH]   Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
               Uttaro, J., Palislamovic, S., and W. Lin, "BGP based
               Multi-homing in Virtual Private LAN Service", Work in
               Progress, July 2014.




























Dutta, et al.                Standards Track                   [Page 26]
^L
RFC 7361           Optimized MAC Withdrawal in H-VPLS     September 2014


Authors' Addresses

   Pranjal Kumar Dutta
   Alcatel-Lucent
   701 E Middlefield Road
   Mountain View, CA  94043
   USA

   EMail: pranjal.dutta@alcatel-lucent.com


   Florin Balus
   Alcatel-Lucent
   701 E Middlefield Road
   Mountain View, CA  94043
   USA

   EMail: florin.balus@alcatel-lucent.com


   Olen Stokes
   Extreme Networks
   2121 RDU Center Drive
   Suite 300
   Morrisville, NC  27650
   USA

   EMail: ostokes@extremenetworks.com


   Geraldine Calvignac
   Orange
   2, avenue Pierre-Marzin
   Lannion Cedex,  22307
   France

   EMail: geraldine.calvignac@orange.com


   Don Fedyk
   Hewlett-Packard Company
   USA

   EMail: don.fedyk@hp.com







Dutta, et al.                Standards Track                   [Page 27]
^L