From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7361.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc7361.txt (limited to 'doc/rfc/rfc7361.txt') 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] + -- cgit v1.2.3