L2VPN Working Group                                  Pranjal Kumar Dutta
                                                            Florin Balus
Internet Draft                                            Alcatel-Lucent
Intended status: Standard
Expires: December 16, 2011                                   Olen Stokes
                                                        Extreme Networks

                                                     Geraldine Calvignac
                                                          France Telecom

                                                         June 23, 2011





       LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
                 draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 23, 2011.

Copyright Notice

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




Dutta, et. al.        Expires December 23, 2011                [Page 1]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   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.



Abstract

   [RFC4762] describes a mechanism to remove or unlearn MAC addresses
   that have been dynamically learned in a 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 an enhancement to the MAC Address Withdrawal
   procedure with empty MAC List [RFC4762], which enables a Provider
   Edge(PE) device to remove only the MAC addresses that need to be
   relearned.

   Additional extensions to [RFC4762] MAC Withdrawal procedures are
   specified to provide optimized MAC flushing for the PBB-VPLS
   specified in [PBB-VPLS Model].

Table of Contents

      1.1. Conventions used in this document.........................3
   2. Introduction...................................................3
   3. Problem Description............................................5
      3.1. MAC Flush optimization in VPLS resiliency.................5
         3.1.1. MAC Flush optimization for regular H-VPLS............5
         3.1.2. MAC Flush optimization for native Ethernet access....7
      3.2. Black holing issue in PBB-VPLS............................8
   4. Solution description...........................................9
      4.1. MAC Flush Optimization for VPLS resiliency................9
         4.1.1. MAC Flush Parameters TLV format.....................10
         4.1.2. Application of MAC Flush TLV in Optimized MAC Flush.11
         4.1.3. MAC Flush TLV Processing Rules for regular H-VPLS...12
         4.1.4. Optimized MAC Flush Procedures......................12
      4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................14
         4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS.........15
   5. Security Considerations.......................................16


Dutta, et. al         Expires December 23, 2011                [Page 2]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   6. IANA Considerations...........................................17
   7. Acknowledgments...............................................17
   8. References....................................................17
      8.1. Normative References.....................................17
      8.2. Informative References...................................17
   Author's Addresses...............................................18


1.1. Conventions used in this document

   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 RFC-2119.

   This document uses the terminology defined in [PBB-VPLS Model],
   [RFC5036], [RFC4447] and [RFC4762]. Throughout this document VPLS
   means the emulated bridged LAN service offered to a customer. H-VPLS
   means the hierarchical connectivity or layout of MTU-s and PE devices
   offering the VPLS [RFC4762]. The terms spoke node and MTU-s in H-VPLS
   are used interchangeably.



2. Introduction

   A method of Virtual Private LAN Service (VPLS), also known as
   Transparent LAN Service (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 Ethernet MAC addresses at the 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.

   [PBB-VPLS Model] describes how Provider Backbone Bridging (PBB) can
   be integrated with VPLS to benefit from 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 number of service instances, PWs and customer MACs (CMACs)
   that need to be handled in the VPLS PEs.





Dutta, et. al         Expires December 23, 2011                [Page 3]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762]
   to remove or unlearn MAC addresses for faster convergence on a
   topology change in resilient H-VPLS topologies.

   An example of the usage of the MAC Flush mechanism is a dual-homed
   H-VPLS where an edge device termed as MTU-s is connected to two PE
   devices via a primary spoke PW and a backup spoke PW, respectively.
   Such redundancy is designed to protect against the failure of the
   primary spoke PW or primary PE device.

   When the MTU-s switches over to the backup PW, it is useful to flush
   the MAC addresses learned in the corresponding VSI in the peer PE
   devices participating in the full mesh to avoid black holing of
   frames to those addresses. Note that a forced switchover to the
   backup PW can be also performed at MTU-s administratively due to
   maintenance activities on the primary spoke PW. When the backup PW is
   made active by the MTU-s it triggers an LDP Address Withdraw Message
   with a list of MAC addresses to be flushed. The message is forwarded
   over the LDP session(s) associated with the newly activated PW. 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. Throughout this document the term MAC Flush Message is used to
   specify an LDP Address Withdraw Message with an empty MAC List
   described in [RFC4762] unless specified otherwise.

   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 for the MAC addresses learned over the newly activated
   PW. The PE device further triggers a MAC flush message to each remote
   PE device connected to it in the VPLS full mesh.

   This method of MAC flushing is modeled after Topology Change
   Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[802.1w].
   When a bridge switches from a failed link to the backup link, the
   bridge sends out a TCN message over the newly activated link. The
   upstream bridge, upon receiving this message, flushes its entire MAC
   addresses except the ones received over this link and 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. When a PE device in the full-mesh of H-VPLS receives a MAC
   flush message it also flushes MAC addresses which are not affected
   due to topology change, thus leading to unnecessary flooding and
   relearning. This document describes the problem and a solution to
   optimize the MAC flush procedure in [RFC4762] so it flushes the
   minimal set of MAC addresses that require relearning when the


Dutta, et. al         Expires December 23, 2011                [Page 4]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   topology changes in H-VPLS. The solution proposed in this document is
   generic and is applicable when MS-PWs are used in interconnecting PE
   devices in H-VPLS.

   [PBB-VPLS Model] describes how PBB can be integrated with VPLS to
   benefit from PBB capabilities while continuing to avoid the use of
   MSTP in the backbone. The combined solution referred as PBB-VPLS
   results in better scalability in terms of number of service
   instances, PWs and CMACs that need to be handled in the VPLS PEs.

   This document also describes extensions to LDP MAC Flush procedures
   described in [RFC4762] required to build desirable capabilities in a
   PBB-VPLS solution.

   Section 3 covers the problem space. Section 4 describes the solution
   and the required TLV extensions.



3. Problem Description

3.1. MAC Flush optimization in VPLS resiliency

3.1.1. MAC Flush optimization for regular H-VPLS

   Figure 1 describes a dual-homed H-VPLS scenario for a VPLS instance
   where the problem with the existing MAC flush method in [RFC4762] is
   explained.


















Dutta, et. al         Expires December 23, 2011                [Page 5]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011








                                 PE-1                         PE-3
                               +--------+                  +--------+
                               |        |                  |        |
                               |   --   |                  |   --   |
   Customer Site 1             |  /  \  |------------------|  /  \  |->
     CE-1               /------|  \ s/  |                  |  \S /  |
       \     primary spoke PW  |   --   |           /------|   --   |
        \             /        +--------+          /       +--------+
         \    (MTU-s)/              |    \        /             |
          +--------+/               |     \      /              |
          |        |                |      \    /               |
          |   --   |                |       \  /                |
          |  /  \  |                |      H-VPLS Full Mesh Core|
          |  \S /  |                |       / \                 |
          |   --   |                |      /   \                |
         /+--------+\               |     /     \               |
        /     backup spoke PW       |    /       \              |
       /              \        +--------+         \--------+--------+
      CE-2             \       |        |                  |        |
   Customer Site 2      \------|  --    |                  |  --    |
                               | /  \   |------------------| /  \   |->
                               | \s /   |                  | \S /   |
                               |  --    |                  |  --    |
                               +--------+                  +--------+
                                 PE-2                         PE-4

           Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS

   In Figure 1, the MTU-s is dual-homed to PE-1 and PE-2. Only the
   primary spoke PW is active at MTU-s, thus PE-1 is acting as the
   active device to reach the full mesh in the VPLS instance. The MAC
   addresses of nodes located at access sites (behind CE1 and CE2) are
   learned at PE-1 over the primary spoke PW. PE-2, PE-3 and PE-4 learn
   those MAC addresses on their respective mesh PWs terminating to PE-1.



Dutta, et. al         Expires December 23, 2011                [Page 6]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   When MTU-s switches to the backup spoke PW and activates it, PE-2
   becomes the active device to reach the full mesh core. Traffic
   entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to
   the spoke PW to PE-2. To avoid traffic black holing the MAC addresses
   that have been learned in the upstream VPLS full-mesh through PE-1
   must be relearned or removed from the MAC FIBs of PE-2, PE-3 and PE-
   4.

   As per the processing rules defined in [RFC4762], on activation of
   the backup PW from MTU-s, a MAC flush message will be sent by MTU-s
   to PE-2 that will flush all the MAC addresses learned in the VPLS
   from all the other PWs except the PWs connected to MTU-s.

   PE-2 further relays MAC flush messages to all other PE devices in the
   full mesh. Same processing rule applies at all those PE devices: all
   the MAC addresses are flushed except the ones learned on the PW to
   PE2. For example, at PE-3 all of the MAC addresses learned from the
   PWs connected to PE-1 and PE-4 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 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 is required that will flush only the MAC addresses
   learned from the PW connected to PE-1 to minimize the relearning and
   flooding in the network.

   Further the forwarding of the MAC Flush by PE-2 delays the overall
   MAC flush propagation time into the core PEs in the full mesh. So it
   is desirable to avoid MAC flush forwarding across multiple PEs as far
   as possible and yet achieve the same desired MAC flushing action.

3.1.2. MAC Flush optimization for native Ethernet access

   The analysis in section 3.1.1 applies also to the native Ethernet
   access into a VPLS where one active and one or more backup endpoints
   into two or more VPLS or H-VPLS PEs are being used. Examples of these
   are [G.8032v2] access rings or any proprietary multi-chassis LAG
   emulations.



Dutta, et. al         Expires December 23, 2011                [Page 7]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   As in the active/standby PWs case from the previous section, upon
   failure of the active native Ethernet endpoint on PE-1 a MAC Flush
   optimization is required to ensure that on PE-2, PE-3 and PE-4 only
   the MAC addresses learned from the PW connected to PE-1 are being
   flushed.

3.2. Black holing issue in PBB-VPLS

   In a PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as the
   infrastructure for one or more I-component instances. B-VPLS control
   plane (LDP Signaling) replaces the I-component control plane
   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 2 describes the case of a CE device (node A)
   dual-homed to two I-component instances located on two PBB-VPLS PEs
   (PE1 and PE2).





                            IP/MPLS Core
                          +--------------+
                          |PE2           |
                         +----+          |
                         |PBB |   +-+    |
                     _   |VPLS|---|P|    |
                       B/+----+  /+-+\   |PE3
                       / +----+ /     \+----+
                 +---+/  |PBB |/  +-+  |PBB |   +---+
         CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
                 +---+ A +----+   +-+  +----+   +---+
                   A      |PE1           |        B
                          |              |
                          +--------------+
        Figure 2: PBB Black holing Issue - CE Dual-Homing use case


   The link between PE1 and CE A is active (marked with A) while the
   link between CE A and PE2 is in Backup/Blocked status. In the network
   diagram CMAC X is one of the MAC addresses located behind CE A in the
   customer domain, CMAC Y is behind CE B and the B-VPLS instances on
   PE1 and PE2 are associated with backbone MAC (BMAC) B1 and BMAC B2,
   respectively.

   As the packets flow from CMAC X to CMAC Y through PE1 with BMAC B1,
   the remote PEs participating in the I-VPLS (for example, PE3) will


Dutta, et. al         Expires December 23, 2011                [Page 8]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   learn the CMAC X associated with BMAC B1 on PE1. Under failure of the
   link between CE A and PE1, and with the activation of link to PE2,
   the remote PEs (for example, PE3) will black hole the traffic
   destined to customer MAC X to BMAC B1 until the aging timer expires
   or a packet flows from X to Y through the PE2 with B2. This may take
   a long time (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
   Flush as specified in [RFC4762] to flush in the B-VPLS domain the
   BMAC associated with the PE where the failure occurred. This will
   automatically flush the CMAC to BMAC association in the remote PEs.
   This solution though has the disadvantage of producing a lot of
   unnecessary MAC flushes in the B-VPLS domain as there was no failure
   or topology change affecting the Backbone domain.

   A better solution is required to propagate the I-component events
   through the backbone infrastructure (B-VPLS) in order to flush only
   the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there
   are no I-VPLS control plane exchanges across the PBB backbone,
   extensions to the B-VPLS control plane are required to propagate the
   I-component MAC Flush events across the B-VPLS.

4. Solution description

4.1. MAC Flush Optimization for VPLS resiliency

   The basic principle of the optimized MAC flush mechanism is explained
   with reference to Figure 1.

   PE-1 would initiate a MAC Flush towards the core on detection of the
   failure of the primary spoke PW between MTU-s and PE-1 (or status
   change from active to standby). This method is referred to as a PE
   initiated MAC Flush throughout this document. The MAC Flush message
   would indicate to receiving PEs to flush all MACs learned over the PW
   in the context of the VPLS over which the MAC flush message is
   received. Each PE device in the full mesh that receives the message
   identifies the VPLS instance and its respective PW that terminates in
   PE-1 from the FEC TLV received in the message. Thus the PE device
   flushes only the MAC addresses learned from that PW connected to PE-1
   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
   referred to as a MAC Flush TLV. A MAC Flush TLV carries information
   on the desired action at the PE device receiving the message and is


Dutta, et. al         Expires December 23, 2011                [Page 9]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   used for optimized MAC flushing in H-VPLS.  The MAC Flush TLV is
   backward compatible and can be used for [RFC4762] style of MAC Flush
   as explained in section 3.1.



4.1.1. MAC Flush Parameters TLV format

   The MAC Flush Parameters TLV is described as 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 Params TLV(TBD) |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     | Sub-TLV Type  |         Sub-TLV Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Sub-TLV Variable Length Value                  |
   |                             "                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The U and F bits are set to forward if unknown so that potential
   intermediate VPLS PEs unaware of the new TLV can just propagate it
   transparently. The MAC Flush Parameters TLV type is to be assigned by
   IANA. The encoding of the TLV follows the standard LDP TLV encoding
   in [RFC5036].

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

   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)

   +-+-+-+-+-+-+-+-+

   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 flush is required. For PBB-VPLS there are two contexts of
     MAC flushing - The Backbone VPLS (B-component VPLS) and Customer


Dutta, et. al         Expires December 23, 2011               [Page 10]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


     VPLS (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush
     for the B-VPLS is required. C flag MUST be set (C=1) when the MAC
     Flush for I-VPLS is required. In the regular H-VPLS case the C flag
     MUST be ZERO (C=0) to indicate 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 is required.
     The source (mine/me) is defined either as the PW associated with
     the LDP session on which the LDP MAC Withdraw was received or with
     the BMAC(s) listed in the BMAC List 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
     4.2.

     MBZ flags, the rest of the flags MUST be set to zero on
     transmission and ignored on reception.

4.1.2. Application of MAC Flush TLV in Optimized MAC Flush

   For the optimized MAC flush, the MAC Flush TLV MAY be sent as in the
   existing LDP Address Withdraw Message with an empty MAC List but from
   the core PE on detection of failure of its local spoke PW. The N bit
   in the TLV MUST be set to 1. 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-VPLS context the C bit MUST be
   set (C= 1). See section 4.2 for PBB-VPLS details.

   Note that if a MAC Flush TLV is not understood by a receiver then it
   may result in undesired action. For example if a MAC Flush Parameters
   TLV is received with N=1 and receiver does not understand that TLV
   then it would result in flushing of all MACs learned in the VSI
   except the ones learned over the PW. The MAC Flush TLV SHOULD be
   placed after the existing TLVs in MAC Flush message in [RFC4762].

   For backward compatibility of MAC flush initiation procedures as
   defined in [RFC4762], the PE-1 MAY send a MAC Flush TLV as an
   OPTIONAL TLV in the MAC Flush Message with N = 0. This would result
   in same flushing action at the receiving PE devices as desired in
   [RFC4762].







Dutta, et. al         Expires December 23, 2011               [Page 11]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


4.1.3.  MAC Flush TLV Processing Rules for regular H-VPLS

   This section describes the processing rules of a MAC Flush TLV that
   SHOULD be followed in the context of MAC flush procedures in an H-
   VPLS.

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

   Note that if MS-PW is used in the VPLS then a MAC flush message is
   processed only at the T-PE nodes since the S-PE(s) traversed by the
   MS-PW propagate MAC flush messages without any action. In this
   section, a PE device signifies only T-PE in the MS-PW case unless
   specified otherwise.

   When a PE 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.

   If a MAC Flush TLV is received with N = 0 in the MAC flush message
   then the receiving PE 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.

   If a PE device receives a MAC flush with the MAC Flush TLV option and
   a valid MAC address list, it SHOULD ignore the option and deal with
   MAC addresses explicitly as per [RFC4762].

   If a PE device that doesn't support MAC Flush TLV receives a MAC
   flush message with this option, it MUST ignore the option and follow
   the processing rules as per [RFC4762]. However if the MAC Flush
   Parameters TLV was sent with N = 1 then it may result in wrong
   flushing action (Positive MAC Flush).

4.1.4. Optimized MAC Flush Procedures

   This section explains the optimized MAC flush procedure in the
   scenario in Figure 1. When the primary spoke PW transition (failure
   or standby transition) is detected by PE-1, it may send MAC flush
   messages to PE-2, PE-3 and PE-4 with a MAC Flush TLV and N = 1. Upon
   receipt of the MAC flush message, PE-2 identifies the VPLS instance
   that requires the MAC flush from the FEC element in the FEC TLV. On
   receiving N=1, PE-2 removes all MAC addresses learned from that PW


Dutta, et. al         Expires December 23, 2011               [Page 12]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   over which the message is received. Same action is followed by PE-3
   and PE-4.

   Figure 3 shows another redundant H-VPLS topology to protect against
   failure of MTU-s device. Provider RSTP may be used as selection
   algorithm for active and backup PWs in order to maintain the
   connectivity between MTU devices and PE devices at the edge. It is
   assumed that PE devices can detect the failure of PWs in either
   direction through OAM mechanisms such as VCCV procedures for
   instance.




               MTU-1----------------PE-1------------PE-3
                 |                  | \             /|
                 |  Redundancy      |  \           / |
                 |  Provider RSTP   |   Full-Mesh .  |
                 |                  |  /           \ |
                 |                  | /             \|
               MTU-2================PE-2------------PE-4
                      Backup PW

               Figure 3: Redundancy with Provider RSTP

   MTU-1, MTU-2, PE-1 and PE-2 participate in provider RSTP. By
   configuration in RSTP it is ensured that the PW between MTU-1 and PE-
   1 is active and the PW between MTU-2 and PE-2 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 PE-2. When PE-1 detects
   the failing PW to MTU-1, it may trigger a MAC flush into the full
   mesh with a MAC Flush TLV that carries N=1. Other PE devices in the
   full mesh that receive the MAC flush message identify their
   respective PWs terminating on PE-1 and flush all the MAC addresses
   learned from it.

   By default, MTU-2 should still trigger MAC flush as currently defined
   in [RFC4762] after the backup PW is made active by RSTP. Mechanisms
   to prevent two copies of MAC withdraws to be sent in such scenarios
   is out of scope of this document.

   [RFC4762] describes multi-domain VPLS services where fully meshed
   VPLS networks (domains) are connected together by a single spoke PW
   per VPLS service between the VPLS "border" PE devices. To provide
   redundancy against failure of the inter-domain spoke, a full mesh of


Dutta, et. al         Expires December 23, 2011               [Page 13]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   inter-domain spokes can be setup between border PE devices and
   provider RSTP may be used for selection of the active inter-domain
   spoke. In case of an inter-domain spoke PW failure, PE initiated MAC
   withdrawal may be used for optimized MAC flushing within individual
   domains.

   Further, the procedures are applicable with any native Ethernet
   access topologies multi-homed to two or more VPLS PEs. The text in
   section 4.1 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 that
   detects the failure in the primary Ethernet access.



4.2. LDP MAC Withdraw Extensions for PBB-VPLS

   The use of Address Withdraw messages with 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 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-component 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 (CMACs)
   to Backbone MAC(s) (BMACs). A topology change in the access (I-
   domain) should just invoke the flushing of CMAC entries in PBB PEs'
   FIB(s) associated with the I-component(s) impacted by the failure.
   There is a need to indicate the PBB PE (BMAC source) that originated
   the MAC Flush message to selectively flush only the MACs that are
   affected.

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



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



Dutta, et. al         Expires December 23, 2011               [Page 14]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   - PBB BMAC List sub-TLV:

   Type: 0x01

   Length: value length in octets. At least one BMAC address must be
   present in the list.

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

   - PBB ISID List sub-TLV:

   Type: 0x02,

   Length: value length in octets. Zero indicates an empty ISID list. An
   empty ISID list means that the flush applies to all the ISIDs mapped
   to the B-VPLS indicated by the FEC TLV.

   Value: one or a list of 24 bits ISIDs that represent the I-component
   FIB(s) where the MAC Flush needs to take place.

4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS

   The following steps describe the details of the processing for the
   related LDP Address Withdraw message:

   . The LDP MAC Withdraw Message, including the MAC Flush Parameters
     TLV is initiated by the PBB PE(s) experiencing a Topology Change
     event in one or multiple customer I-component(s).

          o The flags are set accordingly to indicate the type of MAC
             Flush required for this event: N=0 (Flush-all-but-mine) or
             N = 1 (Flush-all-from-me), C=1 (Flush only CMAC FIBs).

          o The PBB Sub-TLVs (BMAC and ISID Lists) are included
             according to the context of topology change.

   . On reception of the LDP Address Withdrawal message, the B-VPLS
     instances corresponding to the FEC TLV in the message must
     interpret the content of MAC Flush Parameters TLV. If the C-bit is
     set to 1 then Backbone Core Bridges (BCB) in the PBB-VPLS SHOULD
     NOT flush their BMAC FIBs. The B-VPLS control plane SHOULD
     propagate the MAC Flush following the split-horizon grouping and
     the established B-VPLS topology.



Dutta, et. al         Expires December 23, 2011               [Page 15]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   . The usage and processing rules of MAC Flush Parameters TLV in the
     context of Backbone Edge Bridges (BEB) is as follows:

          o  The PBB ISID List is used to determine the particular ISID
             FIBs (I-VPLS) that need to be flushed. If the ISID List is
             empty then all the ISID FIBs associated with the receiving
             B-VPLS SHOULD be flushed.

          o  The PBB BMAC List is used to identify from the ISID FIBs in
             the previous step whether to selectively flush BMAC to CMAC
             associations depending on the N flag specified below.

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

          o  N=0, all the CMACs in the selected ISID FIBs SHOULD be
             flushed with the exception of the identified CMAC list from
             the BMAC List mentioned in the message. ("Flush all but the
             CMACs associated with the BMAC(s) in the BMAC List Sub-TLV
             from the FIBs associated with the ISID list").

          o  N=1, the identified CMAC list SHOULD be flushed ("Flush all
             the CMACs associated with the BMAC(s) in the BMAC List Sub-
             TLV from the FIBs associated with the ISID list").

   4.2.3 Applicability of MAC Flush Parameters TLV

         If a MAC Flush Parameters TLV is received by a BEB in a PBB-
   VPLS that does not understand the TLV then it may result in
   undesirable MAC flushing action. It is RECOMMENDED that all PE
   devices participating in PBB-VPLS support MAC Flush Parameters TLV.

        The MAC Flush Parameters TLV is also applicable to regular VPLS
   contexts. To achieve negative MAC Flush (flush-all-from-me) in a
   regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded
   with C=0 and N = 1 without the inclusion of any Sub-TLVs. Negative
   MAC flush is highly desirable in scenarios when VPLS access
   redundancy is provided by Ethernet Ring Protection as specified in
   [G.8032v2] specification etc.

5. Security Considerations

   Control plane aspects:

   - LDP security (authentication) methods as described in [RFC5036] is
   applicable here. Further this document implements security
   considerations as in [RFC4447] and [RFC4762].



Dutta, et. al         Expires December 23, 2011               [Page 16]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   Data plane aspects:

   - This specification does not have any impact on the VPLS forwarding
   plane.

6. IANA Considerations

   The Type field in MAC Flush Parameters TLV is defined as 0x406 and is
   subject to IANA approval.

7. Acknowledgments

   The authors would like to thank the following people who have
   provided valuable comments and feedback on the topics discussed in
   this document: Marc Lasserre, Ian Cowburn, Dimitri Papadimitriou,
   Jorge Rabadan, Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi,
   Wim Henderickx, Jorge Rabadan and Maarten Vissers.



8. References

8.1. Normative References

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

   [RFC5036] Andersson, L., et al. "LDP Specification", RFC5036, October
             2007.

   [RFC4447] Martini. and et al., "Pseudowire Setup and Maintenance
             Using Label Distribution Protocol (LDP)", RFC 4447, April
             2006.



8.2. Informative References

   [PBB-VPLS Model] F. Balus, et Al. "Extensions to VPLS PE model for
             Provider Backbone Bridging", draft-ietf-l2vpn-pbb-vpls-pe-
             model-00.txt, May 2009 (work in progress)

   [RFC4664] Andersson, L., et al. "Framework for Layer 2 Virtual
             Private Networks (L2VPNs)", RFC 4664, September 2006.




Dutta, et. al         Expires December 23, 2011               [Page 17]


Internet-Draft    Optimized MAC Withdrawal in H-VPLS   June 23, 2011


   [802.1w] "IEEE Standard for Local and metropolitan area networks.
             Common specifications Part 3: Media Access Control (MAC)
             Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std
             802.1w-2001.

   [G.8032v2] ITU-T G.8032v2 specification


Author's 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, USA 94043
   Email: florin.balus@alcatel-lucent.com

   Geraldine Calvignac
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   Email: geraldine.calvignac@orange-ftgroup.com

   Olen Stokes
   Extreme Networks
   PO Box 14129
   RTP, NC  27709
   USA
   Email: ostokes@extremenetworks.com













Dutta, et. al         Expires December 23, 2011               [Page 18]