wdiff rfc7361.original rfc7361.txt

Network Working Group
Internet Engineering Task Force (IETF) P. Dutta
Internet-Draft
Request for Comments: 7361 F. Balus
Intended status:
Category: Standards Track Alcatel-Lucent
Expires: December 29, 2014
ISSN: 2070-1721 O. Stokes
Extreme Networks
G. Calvignac
Orange
D. Fedyk
Hewlett-Packard
June 27,
September 2014

LDP Extensions for Optimized MAC Address Withdrawal
in H-VPLS
draft-ietf-l2vpn-vpls-ldp-mac-opt-13 a Hierarchical Virtual Private LAN Service (H-VPLS)

Abstract

RFC4762

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

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]. RFC 7041.

Status of this This Memo

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

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum 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 six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 31, 2014.
http://www.rfc-editor.org/info/rfc7361.

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.

Table of Contents

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

1. Introduction

A method of Virtual Private LAN Service (VPLS), also known as
Transparent LAN Service (TLS) 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 MAC Media Access Control
(MAC) addresses at the
PE Provider Edge (PE) devices.

This VPLS full mesh 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 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 solution, referred to as PBB-VPLS
"PBB-VPLS", results in better scalability in terms of number of
service instances, PWs PWs, and C-MAC (Customer MAC) Addresses addresses that need
to be handled in the VPLS PEs PEs, depending on the location of the
I-component in the PBB-VPLS topology.

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

Figure 1, 1 is reproduced below from [RFC4762] illustrating 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 Example of a dual-homed Dual-Homed MTU-s

An example usage of the MAC Flush flushing mechanism is the dual-homed
H-VPLS where an edge device termed as Multi Tenant called the Multi-Tenant Unit switch (MTU-
s)[RFC4762],
(MTU-s) [RFC4762] is connected to two PE devices via a primary spoke
PW and backup spoke PW 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 dual-homing in H-VPLS
that are not described in [RFC4762]. For example, note the following
statement from section Section 10.2.1 in of [RFC4762].

"How

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". configuration.

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

2. Terminology

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

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

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

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

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

"MAC Flush Message" means flush message" refers to a Label Distribution Protocol (LDP) Address
Withdraw Message
address withdraw message without a MAC List TLV.

A MAC Flush Message in flush message "in the "context context of a Pseudo Wire (PW)" means PW" refers to the
Message 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 flush message
carries the context of the PW in terms of the Forwarding Equivalence
Class (FEC) TLV associated with the PW
[RFC4762][RFC4447]. [RFC4762] [RFC4447].

In general, "MAC Flush" means flushing" refers to the method of initiating and
processing
of MAC Flush Messages 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 black holing the black-holing of frames to those addresses. This is
accomplished by sending an LDP Address Withdraw Message, address withdraw message -- a new
message defined in this document, document -- from the PE that is no longer
connected to the MTU-s with the primary PW. The new message has the 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 a an LDP Address Withdraw Message address withdraw message
with an empty MAC List. list. When a PE-rs switch in the full-mesh full mesh of H-
VPLS receive
H-VPLS receives this message message, it also flushes MAC addresses which that are
not affected due to the topology change, thus leading to unnecessary
flooding and relearning. Throughout this document document, the term "MAC Flush Message"
flush message" is used to specify an LDP Address Withdraw Message address withdraw message
with an empty MAC
List list as described in [RFC4762]. The solutions
described in this document are applicable only to LDP Address Withdraw Message address
withdraw messages with empty MAC
List. lists.

In a VPLS topology, the core PWs remain active and learning happens
on the PE-rs nodes. However However, when the VPLS topology changes, the
PE-rs must relearn using MAC Addresses address withdrawal or flush. flushing. As per
the MAC Address Withdrawal address withdrawal processing rules in [RFC4762] [RFC4762], a PE device
device, on receiving a MAC Flush Message 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 document, we use the terminology "Positive" "positive" MAC Flush
flushing or "Flush-all-
but-mine" "flush-all-but-mine" for this type of MAC Flush Message flush message
and its actions.

This document introduces an optimized "Negative" "negative" MAC flush message,
described in section 3.2 Section 3.2, that can be configured to improve the
response to topology change changes in a number of Ethernet topologies where
the SLA 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 (ISIDs). service instances (I-SIDs). It is
also important to note that the
Positive MAC Flush flush message described in [RFC4762]
[RFC4762], which is called "a positive MAC flush message" in this
document, MUST always be handled for
BMACs Backbone MACs (B-MACs) in cases
where the core nodes change or fail. Where there is
dual In dual-homed or multihomed multi-homed
edge topology, topologies, the procedures in this document augment [RFC4762]
messages providing and provide less disruption for those cases.

3.1. MAC Flush Flushing on activation Activation of backup spoke Backup Spoke PW

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

3.1.1. PE-rs initiated MAC Flush Flushing Initiated by PE-rs

[RFC4762] specifies that on failure of the primary PW, PW it is the PE3-rs
(Figure 1) that initiates MAC flush flushing towards the core. However However,
note that PE3-rs can initiate MAC Flush flushing only when PE3-rs is dual 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 multihoming multi-
homing protocols. The This document illustrates that multihoming multi-homing can be
improved with the Negative negative MAC flush. flushing. One example is BGP based multi-homing BGP-based multi-
homing in LDP based VPLS that LDP-based VPLS, which uses the procedures defined in [I-D.ietf-
l2vpn-vpls-multihoming].
[VPLS-MH]. In this method of dual-homing, PE3-rs would neither
forward any traffic to the MTU-s nor would it receive any traffic from the
MTU-s while PE1-rs is acting as a primary (or designated forwarder).

3.1.2. MTU-s initiated MAC flush Flushing Initiated by MTU-s

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

MTU-s initiated

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. The upstream bridge upon Upon receiving this message message, the
upstream bridge flushes its entire list of MAC addresses addresses, except the
ones received over this
link and 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.

The MAC Flush flushing information is propagated in the control plane. The
control plane
control-plane message propagation is associated with the data path
and hence follows similar propagation rules similar to those used for propagation as the
forwarding in the LDP data plane. For example example, PE-rs nodes follow
the data plane data-plane "split-horizon" forwarding rules in H-VPLS (Refer (refer to section
Section 4.4 in of [RFC4762]). Therefore Therefore, a MAC Flush 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 flush
message in the context of a mesh PW PW, then it is not propagated to
other mesh PWs.

3.2. MAC Flush Flushing on failure Failure

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

The procedure for negative MAC flush flushing is beneficial and results in
less disruption than the [RFC4762] procedures procedures, including when the MTU-
s
MTU-s is dual homed dual-homed with a variety of Ethernet technologies technologies, not just
LDP. The Negative negative MAC flush message is a more targeted MAC flush flush,
and the other PE-
rs PE-rs nodes will flush only the specified MACs. This
targeted MAC flush cannot be achieved with the MAC Address Withdraw Message address withdraw
message defined in [RFC4762]. The negative Negative MAC flush 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 flush MAC flushing the list SHOULD be
only the MACs for the affected MTU-s. If the list is empty empty, then the
negative MAC flush procedures will result in flushing and relearning
all attached MTU-s's MTU-s devices for the originating PE-rs.

3.3. MAC Flush 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 solution, referred to as "PBB-VPLS" "PBB-VPLS",
results in better scalability in terms of the number of service
instances, PWs PWs, and C-MACs that need to be handled in the VPLS PE-rs
devices. This document describes extensions to LDP MAC Flush flushing
procedures described in [RFC4762] that are required to build
desirable capabilities to for the PBB-VPLS solution.

The solution proposed in this document is generic and is applicable
when Multi Segment Multi-Segment Pseudowires (MS-PW)s (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 respective respect to various
MAC flush flushing actions described in section Section 3.

4.1. MAC Flush Flushing Optimization in VPLS Resiliency

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

4.1.1. MAC Flush Flushing Optimization for regular Regular H-VPLS

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

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

Figure 2: Dual homed Dual-Homed MTU-s in two tier hierarchy 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 MTU-s, thus 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 CE1 CE-1 and CE2) 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 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 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, PE3-rs
PE3-rs, and PE4-rs to X will be blackholed till black-holed until the MAC address
aging timer expires (default (the default is 5 minutes) or a packet flows from
X to other addresses through PE2-rs.

For example, if after the backup spoke PW is active, if a packet flows from MAC Z to MAC X, X after the backup
spoke PW is active, packets from MAC Z travel from PE3-rs to
PE-1rs 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 point,
traffic from PE3-rs to MAC X will go to PE2-rs, since PE-3rs PE3-rs has also
learned about MAC X. Therefore Therefore, a mechanism is required to make this
learning more timely in cases where traffic is not bidirectional.

To avoid traffic blackholing black-holing, the MAC addresses that have been
learned in the upstream VPLS full-mesh full mesh through PE1-rs, PE1-rs must be
relearned or removed from the MAC FIBs Forwarding Information Bases (FIBs)
in the VSIs at PE2-rs, PE3-rs PE3-rs, and PE4-rs. If PE1-rs and PE2-rs are
dual-homing agnostic 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 the other PWs but 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 at for all
those PE-rs devices: all the MAC addresses are flushed but 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
happens, flooding of unknown destination MAC addresses takes place
throughout the network. As the number of PE-rs devices in the full- 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 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 minimizing full mesh, to minimize
the relearning and flooding in the network. In the example above,
only the MAC addresses in set 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 dual-homing
aware and participate in a designated forwarder election. When
PE2-rs becomes the active device for MTU-s the MTU-s, then PE2-rs MAY
initiate MAC flush flushing towards the core. The receiving action of the
MAC Flush flush message in other PE-rs devices is the same as in MTU-s initiated MAC Flush.
flushing initiated by the MTU-s. This is the [RFC4762] behavior specified behavior. in
[RFC4762].

4.1.2. MAC Flush Flushing Optimization for native Native Ethernet access Access

The analysis in section Section 4.1.1 applies also to the native Ethernet
access into a VPLS. In such a scenario scenario, one active endpoint and one
or more standby endpoints terminate into two or more VPLS or H-VPLS
PE-rs devices. Examples of these dual homed this dual-homed access are ITU-T
[ITU.G8032] access rings or any proprietary multi-chassis LAG 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 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 Black-Holing Issue in PBB-VPLS

In a PBB-VPLS deployment 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" Backbone MACs
(BMACs) replaces
(B-MACs) replace the I-component control plane and learning of customer
Customer MACs (CMACs) (C-MACs) throughout the MPLS core. This raises an
additional challenge related to black hole black-hole avoidance in the
I-component domain as described in this section. Figure 3 describes
the case of a CE 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| +-+ |
|VPLS|---|P|
|(B2)|---|P| |
S/+----+
Stby/+----+ /+-+\ |PE3-rs
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
CMAC
C-MAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC |--C-MAC Y
| |Act|(B1)| +-+ | | | |
+---+ A +----+ +-+ +----+ +---+
A |PE1-rs | B
| |
+--------------+

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

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

As the packets flow from CMAC C-MAC X to CMAC C-MAC Y through PE1-rs with BMAC
B-MAC B1, the remote PE-rs devices participating in the B-VPLS with
the same ISID I-SID (for example, PE3-rs) will learn the CMAC C-MAC X
associated with
BMAC B-MAC B1 on PE1-rs. Under a failure condition of the
link between CE-
A CE-A and PE1-rs and on activation of the link to PE2-rs,
the remote PE-
rs PE-rs devices (for example, PE3-rs) will forward the
traffic destined for customer MAC C-MAC X to BMAC B1 B-MAC B1, resulting in PE1-rs blackholing black-
holing that traffic until the aging timer expires or a packet flows
from X to Y through the PE2-rs, BMAC B2. PE2-rs (B-MAC B2). This may take a long time (default
(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
Flush
flushing method as specified in [RFC4762] to flush the BMAC B-MAC
associated with the PE-rs in the B-VPLS domain where the failure
occurred. This will automatically flush the CMAC to BMAC C-MAC-to-B-MAC
association in the remote PE-rs devices. This solution has the
disadvantage of producing a lot of unnecessary MAC flush flushing in the
B-VPLS domain as there was no failure or topology change affecting
the Backbone domain.

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

5. Solution Description

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

5.1. MAC Flush 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 Flush flushing on failure as described in section Section 3.2.

PE1-rs would initiate MAC Flush 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] ). [RFC6718]). This method is
referred to as "MAC Flush flushing on Failure" failure" throughout this document.

The MAC Flush 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 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]. Through out Throughout this document document, the MAC Flush Parameters TLV is
also referred to as the MAC "MAC Flush TLV. 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 Flush flushing as
explained in section Section 3.

5.1.1. MAC Flush Parameters TLV

The MAC Flush Parameters TLV is described as below:

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

The U U-bit and F bits 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 an a B-VPLS network
that has PBB-VPLS in the core with no I-components attached attached, this
message can still be useful to edge B-VPLS devices that do have the
I-components with the ISIDs I-SIDs and understand the message. The MAC
Flush Parameters TLV type is to be 0x0406, as assigned by IANA. The
encoding of the TLV follows the standard LDP TLV encoding described
in [RFC5036] [RFC5036].

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

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

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

1 Byte

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

C flag, used

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

N flag, used

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

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

MBZ flags, the 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 in [RFC4762]. flush message.

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

When optimized MAC flush flushing is supported, the MAC Flush TLV MUST be
sent
as in an existing LDP Address Withdraw Message address withdraw message with an empty MAC List
list but from the core PE-rs on detection of failure of its
local/primary spoke PW. The N bit N-bit in the TLV MUST be set to 1 to
indicate Flush-all-
from-me. flush-all-from-me. If the optimized MAC Flush flush procedure is
used in a Backbone VPLS or regular VPLS/H-VPLS context context, the C bit C-bit
MUST be ZERO (C=0). (C = 0). If it is used in an I-component context context, the C bit
C-bit MUST be set (C= (C = 1). See section Section 5.2 for details of its usage
in PBB-VPLS context. the context of PBB-VPLS.

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

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

For flush messages.

In the case of B-VPLS devices 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 flush 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 Psuedowire 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 nodes, since PW Switching Provider Edge S-PE(s) traversed
by the MS-PW propagate 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 flush message is received. It is assumed
that when these procedures are used all nodes support the MAC Flush
Message. flush
message. See section Section 6 Operational Considerations ("Operational Considerations") for details.

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

Regardless of whether Optimized optimized MAC flush flushing is supported, if a PE-rs
device receives a MAC flush message with a MAC Flush TLV option
(N = 0 or N= 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 optimized MAC flush flushing is being used used, a PE-rs that is dual dual-
homing aware SHOULD send MAC address messages with a MAC Flush TLV
and N=1 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 flush flushing from the FEC element in the FEC TLV. On
receiving
N=1, PE-2 N = 1, PE2-rs removes all MAC addresses learned from that
PW over which the message is received. The same action is followed 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 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 such as VCCV procedures
for instance.

MTU-1================PE-1-rs=============PE-3-rs OAM mechanisms (for
instance, Virtual Circuit Connectivity Verification (VCCV)
procedures).

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

Figure 4: Redundancy with Provider RSTP

MTU-1, MTU-2, PE1-rs PE1-rs, and PE2-rs participate in provider RSTP. By
configuration in
Configuration using RSTP it is ensured 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 flush flushing into the
full mesh with a MAC Flush TLV that carries N=1. N = 1. Other PE-rs
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 setup set up between border PE-rs devices devices, and
provider RSTP may be used for selection of the active inter-domain
spoke. In the case of inter-domain spoke PW failure, PE-rs initiated MAC withdrawal
initiated by PE-rs MAY be used for optimized MAC flushing flush procedures
within individual domains.

Further, the procedures are applicable with 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 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 Address Withdraw 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. (e.g., failure of a primary link
of a VPLS PE-rs device and implicitly and, implicitly, the activation of an
alternate link in a dual-
homing dual-homing use case). These existing procedures
apply individually to B-VPLS and I-component domains.

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

MAC Switching switching in PBB is based on the mapping of Customer MACs (CMACs)
(C-MACs) to one or more Backbone MAC(s) (BMACs). MACs (B-MACs). A topology change in
the access
(I-domain) (I-component domain) should just invoke the flushing of CMAC
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 (BMAC (B-MAC source) that originated the MAC Flush 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 address withdraw message to indicate the particular
domain(s) requiring MAC flush. 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).

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 BMAC B-MAC List Sub-TLV:

Type: IANA TBDB 0x0407

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

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

o PBB ISID I-SID List Sub-TLV:

Type: IANA TBDC 0x0408

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

Value: one One or a list of 24 bits ISIDs 24-bit I-SIDs that represent the
I-component FIB(s) where the MAC Flush 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 general, these
procedures are similar to the VPLS case but are tailored to PBB PBB,
which may have a large number of MAC addresses. In PBB PBB, there are
two sets of MAC addresses addresses: Backbone (outer) MACs (BMACs) (B-MACs) and
Customer (inner) MACs (CMACs). (C-MACs). C-MACs are associated to remote
B-MACs by learning. There are also ISIDs which I-SIDs in PBB; I-SIDs are similar
to VLANs for the purposes of the discussion in this description. section. In
order to get the achieve behavior that is similar to the Regular VPLS case case,
there are some differences in the interpretation of the Optimized optimized MAC
flush message.

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

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

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

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

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

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

- A set of BMACs B-MACs SHOULD be listed listed, since BMAC to CMAC B-MAC-to-C-MAC
associations need to be flushed and listing BMACs B-MACs scopes the
flush to just those BMACs. Again B-MACs. Again, this is typical usage usage,
because a PBB VPLS I-
component I-component interface will have one
associated ISID I-SID and typically one but (but possibly more than one BMAC one)
B-MAC, each with multiple remotely learned CMACs. C-MACs. The BMAC 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 CMACs C-MACs that are
associated with any BMACs B-MACs in the list (in other words words, from the
affected interface.) interface).

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

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

- On Backbone Edge Bridges (BEB) is as follows: (BEBs), the following actions apply:

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

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

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

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

- N=1, N = 1: all the resulted CMACs resultant C-MACs SHOULD be flushed ("Flush ("flush all
the
CMACs C-MACs associated with the BMAC(s) B-MAC(s) in the BMAC B-MAC List
Sub-TLV from the FIBs associated with the ISID 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 Bridges Bridge
(BEB) in a PBB-VPLS that does not understand the TLV TLV, then it may
result in an
undesirable MAC flushing action. 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 possible, the MAC Flush Parameters
TLV SHOULD be disabled disabled, as mentioned in section Section 6 Operational
Considerations. ("Operational
Considerations").

"Mac Flush TLV" and its formal name -- "MAC Flush Parameters TLV" --
are synonymous. The MAC Flush Parameters TLV is also applicable to the regular VPLS
context as well well, as explained in section Section 3.1.1. To achieve negative
MAC Flush flushing (flush-all-from-me) in a regular VPLS context, the MAC
Flush Parameters TLV SHOULD be encoded with C=0 C = 0 and N = 1 without
inclusion of any Sub-TLVs. Negative A negative MAC flush message is highly
desirable in scenarios
when where VPLS access redundancy is provided by
Ethernet Ring Protection ring protection as specified in the ITU-T [ITU.G8032]specification. G.8032 [ITU.G8032]
specification.

6. Operational Considerations

As mentioned earlier, if the MAC Flush Parameters TLV is not
understood by a receiver receiver, then it would result in undesired an undesirable MAC flushing
action. action
would result. To avoid this, one possible solution is to develop an LDP
based
LDP-based capability negotiation mechanism to negotiate support of
various MAC Flushing capability 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 flush flushing as described in this
document.

VPLS may be used with or without the optimization. If an operator
wants the optimizations optimization for VPLS 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 flushing
action towards a PE-rs device in the VPLS. Thus Thus, in the topology
described in figure Figure 2, an implementation could support PE1-rs PE1-rs,
sending optimized MAC Flush flush messages towards the PE-rs devices that
support the solution and the PE2-rs device initiating the [RFC4762]
style of MAC Flush flush messages towards the PE-
rs 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 RFC4762 RFC 4762 MAC flush procedures
flushing procedures, since this document only augments them.

For

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

7. IANA Considerations

7.1

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 is requested to allocate has allocated three new code points from the
unassigned range 0x0405-0x04FF as follows. IANA is requested to
allocate consecutive numbers. follows:

7.2

7.2. New Registry for MAC Flush Flags

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

IANA is requested to populate has populated the registry as follows:

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

8. Security Considerations

Control plane

Control-plane aspects:

LDP security (authentication) methods as described in [RFC5036] is
are applicable here. Further 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

Data-plane aspects:

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

9. Contributing Author

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

Marc Lasserre
Alcatel-Lucent

Email:
EMail: marc.lasserre@alcatel-lucent.com

10. Acknowledgements

The authors would like to thank the following people who have
provided valuable comments, feedback 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
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. 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

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

[I-D.ietf-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
Palislamovic, S., Uttaro, J., and W. Lin, "BGP based
Multi-homing in Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-multihoming-06 (work in progress),
October 2012.

[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 Telecommunications Telecommunication Union, "Ethernet ring
protection switching", ITU-T Recommendation G.8032,
March 2010.
February 2012.

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

[RFC6718] Muley, P., Aissaoui, M., and Bocci, M., "Pseudowire
Redundancy",

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

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, M., "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.

Authors' Addresses

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

Email:

EMail: pranjal.dutta@alcatel-lucent.com

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

Email:

EMail: florin.balus@alcatel-lucent.com

Olen Stokes
Extreme Networks
PO Box 14129, RTP
Raleigh, North Carolina 27709
2121 RDU Center Drive
Suite 300
Morrisville, NC 27650
USA

Email:

EMail: ostokes@extremenetworks.com

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

Email:

EMail: geraldine.calvignac@orange.com

Don Fedyk
Hewlett-Packard Company
USA
Email:

EMail: don.fedyk@hp.com