summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7361.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7361.txt')
-rw-r--r--doc/rfc/rfc7361.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7361.txt b/doc/rfc/rfc7361.txt
new file mode 100644
index 0000000..ce9d250
--- /dev/null
+++ b/doc/rfc/rfc7361.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+