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

                                                     Geraldine Calvignac
                                                         France Telecom

                                                        July 9,

                                                       October 25, 2010

       LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 9, 2009. April 25, 2011.

Copyright Notice

   Copyright (c) 2010 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.


   [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

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

Table of Contents

   1. Introduction...................................................3

      1.1. Conventions used in this document.........................3
   2. Introduction...................................................3
   3. Problem Description............................................5
      3.1. MAC Flush in regular H-VPLS...............................5
      2.2. Blackholing
      3.2. Black holing issue in PBB-VPLS.............................6
   3. PBB-VPLS............................7
   4. Solution description...........................................8
      4.1. MAC Flush Optimization for regular H-VPLS.................8
         4.1.1. PE-ID TLV Format.....................................8
         4.1.2. Application of PE-ID TLV in Optimized MAC Flush.....11
         4.1.3. PE-ID TLV Processing Rules..........................11
         4.1.4. Optimized MAC Flush Procedures......................12
      4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................13
         3.2.1. PBB-VPLS.................14
         4.2.1. MAC Flush Parameters TLV format.....................14
         4.2.2. MAC Flush Parameters TLV Processing Rules...........16
   5. Security Considerations.......................................17
   5. IANA Considerations...........................................17
   6. Acknowledgments...............................................17 IANA Considerations...........................................18
   7. References....................................................17
      7.1. Acknowledgments...............................................18
   8. References....................................................18
      8.1. Normative References.....................................17
      7.2. References.....................................18
      8.2. Informative References...................................18
   Author's Addresses...............................................18 Addresses...............................................19

1.1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 on 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].

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

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

   An example of usage of the MAC Flush mechanism is the dual-homed H-
   H-VPLS where an edge device termed as MTU-s is connected to two PE
   devices via primary spoke PW and backup spoke PW respectively. Such
   redundancy is designed to protect against the failure of primary
   spoke PW or primary PE device. When the MTU-s switches over to the
   backup PW, it is required to flush the MAC addresses learned in the
   corresponding VSI in peer PE devices participating in full mesh, to
   avoid black holing of frames to those addresses. Note that forced
   switchover to 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 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 a LDP Address
   Withdraw Message with an empty MAC List. Throughout this document the
   term MAC Flush Message is used to specify LDP Address Withdraw
   Message with empty MAC List described in [RFC4762] unless specified

   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 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 only the
   set of MAC addresses that require relearning when topology changes in
   H-VPLS. The solution proposed in this document is generic and is
   applicable to when MS-PWs are used in interconnecting PE devices in

   [PBB-VPLS Model] 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 as PBB-VPLS
   results in better scalability in terms of number of service
   instances, PWs and C-MACs that need to be handled in the VPLS PEs.

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

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

3. Problem Description

3.1. MAC Flush in 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

                                 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.
   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 backup spoke PW. For faster convergence MTU-s may desire to
   unlearn or remove the MAC addresses that have been learned in the
   upstream VPLS full-mesh through PE-1. MTU-s may send a MAC flush
   message to PE-2 once the backup PW has been made active. As per the
   processing rules defined in [RFC4762], PE-2 flushes the MAC addresses
   learned in the VPLS from the PWs terminating at PE-1, PE-3 and PE-4.

   In the H-VPLS core, PE devices are connected in full mesh unlike the
   spanning tree connectivity in bridges. So the MAC addresses that
   require flushing and relearning at PE-2 are only the MAC addresses
   those have been learned on the PW connected to PE-1.

   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. 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. 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 large
   number of VPLS instances provisioned in the H-VPLS network topology
   the amount of unnecessary flooding and relearning increases.

3.2. Blackholing Black holing issue in PBB-VPLS

   In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as
   infrastructure for one or more I-component instances. B-VPLS control
   plane (LDP Signaling) replaces I-component control plane throughout
   the MPLS core. This is raising 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|    |
                       S/+----+  /+-+\   |PE3
                       / +----+ /     \+----+
                 +---+/  |PBB |/  +-+  |PBB |   +---+
         CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
                 +---+ A +----+   +-+  +----+   +---+
                   A      |PE1           |        B
                          |              |
        Figure 2: PBB Blackholing 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 Standby/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 BVPLS
   instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2
   with BMAC B2.

   As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the
   remote PEs participating in the IVPLS (for example, PE3) will learn
   the CMAC X associated with BMAC B1 on PE1. Under failure of the link
   between CE A and PE1 and activation of link to PE2, the remote PEs
   (for example, PE3) will black-hole the traffic destined for customer
   MAC X to BMAC B1 until the aging timer expires or a packet flows from
   X to Y through the PE 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 BVPLS 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 flush 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 IVPLS control plane exchanges across the PBB backbone,
   extensions to 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 regular H-VPLS

   The basic principle of the optimized MAC flush mechanism is explained
   with reference to Figure 1. On switching over to the backup spoke PW
   when MTU-s triggers MAC flush message to PE-2, it also communicates
   the unique PW endpoint identifier (PE-ID) in PE-1, the formerly
   active PE device. In VPLS a PW terminates on a Virtual Switching
   Instance (VSI) in a PE device. The PE-ID is relayed in all the
   subsequent MAC flush messages triggered by PE-2 to its peer PE
   devices in the full mesh. Each PE device that receives the message
   identifies the VPLS (From FEC TLV) and its respective PW that
   terminates in PE-1 (from PE-ID). Thus the PE device flushes only the
   MAC addresses learned from that PW connected to PE-1.

   This section defines a PW Endpoint Identifier (PE-ID) TLV for LDP
   [RFC5036]. The PE-ID TLV carries the unique identifier of a generic
   PW endpoint.

  4.1.1. PE-ID TLV Format

   The encoding of PE-ID TLV follows standard LDP TLV encoding in
   [RFC5036]. A PE-ID TLV contains a list of one or more PE-ID Elements.
   Its encoding is:

      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|0|  PE-ID  TLV (0x0405)      |            Length             |
     |                        PE-ID Element 1                        |
     |                                                               |
     ~                                                               ~
     |                                                               |
     |                        PE-ID Element n                        |

   U (Unknown) bit of thus LDP TLV MUST be set to 1. If the PE-ID TLV is
   not understood then it is ignored the receiving device.

   F (Forward) MUST be set to 0. Since the LDP mechanism used here is
   targeted, the TLV is not forwarded if it is not understood by the
   receiving device.

   The Type field MUST be set to 0x405 (subject to IANA approval). This
   identifies the TLV type as PE-ID TLV.

   Length field specifies the total length in octets of the Value in PE-
   ID TLV.

   PE-ID Element 1 to PE-ID Element n: there are several types of PE-ID
   Elements. The PE-ID Element Encoding depends on the type of the PE-ID
   Element. A PE-ID Element uniquely identifies a PW Endpoint.

   A PE-ID Element value is encoded as 1 octet field that specifies the
   element type, 1 octet field that identifies the length in octets of
   the element value, and a variable length field that is type dependent
   element value.

   The PE-ID Element value encoding is:

   PE-ID name        Type              Length             Value

   FEC-128 specific   0x01            12 octets         See below.

   FEC-129 specific   0x02            Variable          See below.

   The type of PE-ID Element depends on the type of FEC Element used to
   provision the respective PW. [RFC4447] defines two types of FEC
   elements that may be used for provisioning PWs - Pwid FEC (type 128)
   and the Generalized ID (GID) FEC (type 129). The Pwid FEC element
   includes a fixed-length 32 bit value called the PWid. The same PWid
   value must be configured on the local and remote PE prior to PW
   setup. The GID FEC element includes TLV fields for attachment
   individual identifiers (AII) that, in conjunction with an attachment
   group identifier (AGI), serve as PW endpoint identifiers. The
   endpoint identifier on the local PE (denoted as <AGI, source AII or
   SAII>) is called the source attachment identifier (SAI) and the
   endpoint identifier on the remote PE (denoted as <AGI, target AII or
   TAII>) is called the target attachment identifier (TAI). The SAI and
   TAI can be distinct values. This is useful for provisioning models
   where the local PE (with a particular SAI) does not know and must
   somehow learn (e.g. via MP-BGP auto-discovery) of remote TAI values
   prior to launching PW setup messages towards the remote PE.

   FEC-128 specific PE-ID Element

   This sub-type is to be used to identify a PW endpoint only if Pwid
   FEC Element is used for signaling the PW. The encoding of this PE-ID
   element is as follows:

     |     0x01      |    Length     |           PW type             |
     |                           PW ID                               |
     |                      Endpoint Address                         |

     PW type: The PW Type value from PWid FEC element.

     PW ID: The PW ID value from the Pwid FEC element.

     Endpoint Address: 32-bit LSR-ID from the LDP-ID used in LDP
     signaling Session by a PW endpoint.

   FEC-129 specific PE-ID element

   This sub-type is to be used to indentify a PW endpoint only if GID
   FEC Element is used for signaling the PW. The encoding of this PE-ID
   element is as follows:

    |     0x02      |    Length     |           PW type             |
    |                           AGI TLV                             |
    |                           AII TLV                             |

   PW type: The PW Type value from GID FEC element.

   PW ID: The PW ID value from the GID FEC element.

   AGI TLV: The AGI from the corresponding GID Element

   AII TLV: The AII associated with the PW endpoint.

  4.1.2. Application of PE-ID TLV in Optimized MAC Flush

   For optimized MAC flush, the PE-ID TLV MAY be sent as an OPTIONAL
   parameter in existing LDP Address Withdraw Message with empty MAC
   List. The PE-ID TLV carries the unique PW endpoint identifier in a
   VPLS as described in section 4.

   It is to note that for optimized MAC flush the PE-ID TLV carries
   sufficient information for identifying the VPLS instance and the
   unique VSI Identifier. For backward compatibility with MAC flush
   procedures in [RFC4762] both FEC TLV and PE-ID TLV should be sent in
   the MAC flush message. However the inclusion of the FEC-TLV should be
   based on what would be the desired effect should the PE-ID not be
   understood by the receiver.  In cases where the desired action when
   the PE-ID is not understood would be to behave as described in
   [RFC4762], then the FEC TLV SHOULD be always included.  In cases
   where the desired action when the PE-ID is not understood is no mac
   flushing, then the FEC TLV SHOULD NOT be included. The PE-ID TLV
   SHOULD carry the unique VSI identifier in the VPLS instance
   (specified in the FEC TLV). The PE-ID TLV SHOULD be placed after the
   existing TLVs in MAC Flush message in [RFC4762].

  4.1.3.  PE-ID TLV Processing Rules

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

   When an MTU-s triggers MAC flush after activation of backup spoke PW,
   it MAY send the PE-ID TLV that identifies VSI in the formerly active
   PE device. There may be cases where a PE device in full mesh
   initiates MAC flush torwards towards the core when it detects a spoke PW
   failure. In such a case the PE-ID TLV in MAC flush message MAY
   identify its own VSI. Irrespective of whether it is the MTU-s or PE
   device that initiates the MAC flush, a PE device receiving the PE-ID
   TLV SHOULD follow the same processing rules as described in this

   Note that if MS-PW is used in VPLS then a MAC flush message is
   processed only at the T-PE nodes since 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 MS-PW case unless specified

   When a PE device receives a MAC flush with PE-ID TLV, it SHOULD flush
   all the MAC addresses learned from the PW that terminates in the
   remote VSI identified by the PE-ID element.

   If a PE-ID element received in the MAC flush message identifies the
   local VSI, it SHOULD flush the MAC addresses learned from its local
   spoke PW(s) in the VPLS instance.

   If a PE device receives a MAC flush with the PE-ID 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 PE-ID TLV receives a MAC flush
   message with this option, it MUST ignore the option and follow the
   processing rules as per [RFC4762].

  4.1.4. Optimized MAC Flush Procedures

   This section explains the optimized MAC flush procedure in the
   scenario in Figure 1. When the backup PW is activated by MTU-s, it
   may send MAC flush message to PE-2 with the FEC TLV and the optional
   PE-ID TLV. The PE-ID element carries the VSI identifier in PE-1 for
   the VPLS. Upon receipt of the MAC flush message, PE-2 identifies the
   VPLS instance that requires MAC flush from the FEC element in the FEC
   TLV. From the PE-ID TLV, PE-2 identifies the PW in the VPLS that
   terminates in PE-1. PE-2 removes all MAC addresses learned from that
   PW. PE-2 relays MAC flush messages with the received PE-ID to all its
   peer PE devices. When the message is received at PE-3, it identifies
   the PW that terminates in the remote VSI in PE-1. PE-3 removes all
   MAC addresses learned on the PW that terminated in PE1. There may be
   redundancy scenerios where a PE device in the full mesh may be
   required to initiate optimized MAC Address Withdrawal. Figure 3 shows
   a 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 failure on PWs in either direction through OAM mechanisms such
   as VCCV procedures for instance.

                 ||                  || \             /||
                 ||  Redundancy      ||  \           / ||
                 ||  Provider RSTP   ||   Full-Mesh .  ||
                 ||                  ||  /           \ ||
                 ||                  || /             \||
                      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 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 MAC flush into the full mesh
   with PE-ID TLV that carries its own VSI identifier in the VPLS. 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 service 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, full mesh of
   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 inter-domain spoke PW failure, PE initiated MAC
   withdrawal may be used for optimized MAC flushing within individual

4.2. LDP MAC Withdraw Extensions for PBB-VPLS

   The use of Address Withdraw message 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. message to selectively flush only the MACs that are

   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. At 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).

  4.2.1. MAC Flush Parameters TLV format

   A suggested structure for

   The MAC Flush Parameters TLV is depicted 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 UF 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 value is to be assigned by
   IANA. The Length field is used to define the length encoding of the TLV including
   the type and follows the length itself. standard LDP TLV encoding
   in [RFC5036].

   The TLV value field contains an one byte Flag field used as described
   below. A number of sub-TLVs may be
   also defined inside Further the TLV value field. may carry one or more sub-TLVs. Any sub-TLV 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: defined :

     C flag, used to indicate whether the MAC Flush is required in the
     FIB associated with the VPLS context of the PBB-VPLS component in
     which LDP MAC Flush was
     received. flush is required. For PBB-VPLS this is called there are two contexts of
     MAC flushing - The Backbone VPLS. VPLS (B-component VPLS) and Customer
     VPLS (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush
     for the Backbone VPLS (B-component
     VPLS) B-VPLS is required. C flag MUST be set (C=1) when the MAC
     Flush for
     Customer VPLS (I-component VPLS) I-VPLS is required.

     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 Sub-TLV.

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

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

   - 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.2. MAC Flush Parameters TLV Processing Rules

   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),
             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 related corresponding to the FEC TLV from in the LDP Address Withdraw 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
     BCBs should not PBB-VPLS SHOULD
     NOT flush their BMAC FIBs. The B-VPLS control plane
     may SHOULD
     propagate the MAC Flush indication following the split-horizon grouping and
     the established BVPLS B-VPLS topology.

   . The receiving BEBs use the sub-TLVs from 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 are SHOULD be flushed.

          o  The PBB BMAC List is used to identify from the ISID FIBs
             in the previous step just the entries that map
             CMACs to selectively flush BMAC to CMAC
             associations depending on the BMACs that are not listed in the sub-TLV. 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 SHOULD be
             flushed with the exception of the resulted 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 resulted CMAC list should 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") list").

   4.2.3 Applicability of MAC Flush Parameters TLV

         If 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
   context as well. To achieve negative MAC Flush (flush-all-from-me) in
   regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded
   with C=0 and N = 1 without 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 ITU-T G.8032
   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].

   Data plane aspects:

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

6. IANA Considerations

   The Type field in PE-ID TLV is defined as 0x405 and is subject to
   IANA approval.

   IANA needs to assign

   The Type field in MAC Flush Parameters TLV type values. 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, 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

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

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.

   [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

Author's Addresses

   Pranjal Kumar Dutta
   701 E Middlefield Road,
   Mountain View, CA 94043
   Email: pranjal.dutta@alcatel-lucent.com

   Florin Balus
   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
   Email: geraldine.calvignac@orange-ftgroup.com

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