LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
draft-ietf-l2vpn-vpls-ldp-mac-opt-06
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (l2vpn WG) | |
|---|---|---|---|
| Authors | Pranjal Dutta , Florin Balus , Olen Stokes , Geraldine Calvignac | ||
| Last updated | 2012-05-20 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
OPSDIR Telechat review
(of
-12)
Not Ready
OPSDIR Last Call review
(of
-11)
Serious Issues
GENART Last Call review
(of
-11)
Ready with Issues
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-l2vpn-vpls-ldp-mac-opt-06
L2VPN Working Group Pranjal Kumar Dutta
Florin Balus
Internet Draft Alcatel-Lucent
Intended status: Standard
Expires: November 20, 2012 Olen Stokes
Extreme Networks
Geraldine Calvignac
France Telecom
May 20, 2012
LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
draft-ietf-l2vpn-vpls-ldp-mac-opt-06.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 20, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dutta, et. al. Expires November 20, 2012 [Page 1]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
[RFC4762] describes a mechanism to remove or unlearn MAC addresses
that have been dynamically learned in a VPLS Instance for faster
convergence on topology change. The procedure also removes MAC
addresses in the VPLS that do not require relearning due to such
topology change.
This document defines an enhancement to the MAC Address Withdrawal
procedure with empty MAC List [RFC4762], which enables a Provider
Edge(PE) device to remove only the MAC addresses that need to be
relearned.
Additional extensions to [RFC4762] MAC Withdrawal procedures are
specified to provide optimized MAC flushing for the PBB-VPLS
specified in [PBB-VPLS Model].
Table of Contents
1.1. Conventions used in this document.........................3
2. Introduction...................................................3
3. Problem Description............................................5
3.1. MAC Flush optimization in VPLS resiliency.................5
3.1.1. MAC Flush optimization for regular H-VPLS............5
3.1.2. MAC Flush optimization for native Ethernet access....7
3.2. Black holing issue in PBB-VPLS............................8
4. Solution description...........................................9
4.1. MAC Flush Optimization for VPLS resiliency................9
4.1.1. MAC Flush Parameters TLV format.....................10
4.1.2. Application of MAC Flush TLV in Optimized MAC Flush.11
4.1.3. MAC Flush TLV Processing Rules for regular H-VPLS...12
4.1.4. Optimized MAC Flush Procedures......................12
4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................14
4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS.........15
5. Security Considerations.......................................16
Dutta, et. al Expires November 20, 2012 [Page 2]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
6. IANA Considerations...........................................17
7. Acknowledgments...............................................17
8. References....................................................17
8.1. Normative References.....................................17
8.2. Informative References...................................17
Author's Addresses...............................................18
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
This document uses the terminology defined in [PBB-VPLS Model],
[RFC5036], [RFC4447] and [RFC4762]. Throughout this document VPLS
means the emulated bridged LAN service offered to a customer. H-VPLS
means the hierarchical connectivity or layout of MTU-s and PE devices
offering the VPLS [RFC4762]. The terms spoke node and MTU-s in H-VPLS
are used interchangeably.
2. Introduction
A method of Virtual Private LAN Service (VPLS), also known as
Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is
created using a collection of one or more point-to-point pseudowires
(PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh
topology provides a LAN segment or broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses at the
PE devices.
This VPLS full mesh core configuration can be augmented with
additional non-meshed spoke nodes to provide a Hierarchical VPLS (H-
VPLS) service [RFC4762]. Throughout this document this configuration
is referred to as "regular" H-VPLS.
[PBB-VPLS Model] describes how Provider Backbone Bridging (PBB) can
be integrated with VPLS to allow for useful PBB capabilities while
continuing to avoid the use of MSTP in the backbone. The combined
solution referred to as PBB-VPLS results in better scalability in
terms of number of service instances, PWs and C-MACs that need to be
handled in the VPLS PEs.
Dutta, et. al Expires November 20, 2012 [Page 3]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762]
to remove or unlearn MAC addresses for faster convergence on topology
change in resilient H-VPLS topologies.
An example of usage of the MAC Flush mechanism is the dual-homed
H-VPLS where an edge device termed as MTU-s is connected to two PE
devices via primary spoke PW and backup spoke PW respectively. Such
redundancy is designed to protect against the failure of primary
spoke PW or primary PE device.
When the MTU-s switches over to the backup PW, it is required to
flush the MAC addresses learned in the corresponding VSI in peer PE
devices participating in full mesh, to avoid black holing of frames
to those addresses. Note that forced switchover to backup PW can be
also performed at MTU-s administratively due to maintenance
activities on the primary spoke PW. When the backup PW is made active
by the MTU-s, it triggers LDP Address Withdraw Message with a list of
MAC addresses to be flushed. The message is forwarded over the LDP
session(s) associated with the newly activated PW. In order to
minimize the impact on LDP convergence time and scalability when a
MAC List TLV contains a large number of MAC addresses, many
implementations use a LDP Address Withdraw Message with an empty MAC
List. Throughout this document the term MAC Flush Message is used to
specify LDP Address Withdraw Message with empty MAC List described in
[RFC4762] unless specified otherwise.
As per the MAC Address Withdrawal processing rules in [RFC4762] a PE
device on receiving a MAC flush message removes all MAC addresses
associated with the specified VPLS instance (as indicated in the FEC
TLV) except the MAC addresses learned over the newly activated PW.
The PE device further triggers a MAC flush message to each remote PE
device connected to it in the VPLS full mesh.
This method of MAC flushing is modeled after Topology Change
Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[802.1w].
When a bridge switches from a failed link to the backup link, the
bridge sends out a TCN message over the newly activated link. The
upstream bridge upon receiving this message flushes its entire MAC
addresses except the ones received over this link and sends the TCN
message out of its other ports in that spanning tree instance. The
message is further relayed along the spanning tree by the other
bridges. When a PE device in the full-mesh of H-VPLS receives a MAC
flush message it also flushes MAC addresses which are not affected
due to topology change, thus leading to unnecessary flooding and
relearning. This document describes the problem and a solution to
optimize the MAC flush procedure in [RFC4762] so it flushes only the
set of MAC addresses that require relearning when topology changes in
Dutta, et. al Expires November 20, 2012 [Page 4]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
H-VPLS. The solution proposed in this document is generic and is
applicable when MS-PWs are used in interconnecting PE devices in
H-VPLS.
[PBB-VPLS Model] describes how PBB can be integrated with VPLS to
allow for useful PBB capabilities while continuing to avoid the use
of MSTP in the backbone. The combined solution referred as PBB-VPLS
results in better scalability in terms of number of service
instances, PWs and C-MACs that need to be handled in the VPLS PEs.
This document describes also extensions to LDP MAC Flush procedures
described in [RFC4762] required to build desirable capabilities to
PBB-VPLS solution.
Section 3 covers the problem space. Section 4 describes the solution
and the required TLV extensions.
3. Problem Description
3.1. MAC Flush optimization in VPLS resiliency
3.1.1. MAC Flush optimization for regular H-VPLS
Figure 1 describes a dual-homed H-VPLS scenario for a VPLS instance
where the problem with the existing MAC flush method in [RFC4762] is
explained.
Dutta, et. al Expires November 20, 2012 [Page 5]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
PE-1 PE-3
+--------+ +--------+
| | | |
| -- | | -- |
Customer Site 1 | / \ |------------------| / \ |->
CE-1 /------| \ s/ | | \S / |
\ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+
\ (MTU-s)/ | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full Mesh Core|
| \S / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ backup spoke PW | / \ |
/ \ +--------+ \--------+--------+
CE-2 \ | | | |
Customer Site 2 \------| -- | | -- |
| / \ |------------------| / \ |->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE-2 PE-4
Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS
In Figure 1, the MTU-s is dual-homed to PE-1 and PE-2. Only the
primary spoke PW is active at MTU-s, thus PE-1 is acting as the
active device to reach the full mesh in the VPLS instance. The MAC
addresses of nodes located at access sites (behind CE1 and CE2) are
learned at PE-1 over the primary spoke PW. PE-2, PE-3 and PE-4 learn
those MAC addresses on their respective mesh PWs terminating to PE-1.
Dutta, et. al Expires November 20, 2012 [Page 6]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
When MTU-s switches to the backup spoke PW and activates it, PE-2
becomes the active device to reach the full mesh core. Traffic
entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to
the spoke PW to PE-2. To avoid traffic blackholing the MAC addresses
that have been learned in the upstream VPLS full-mesh through PE-1
must be relearned or removed from the MAC FIBs of PE-2, PE-3 and PE-
4.
As per the processing rules defined in [RFC4762], on activation of
the standby PW from MTU-s,a MAC flush message will be sent by MTU-s
to PE-2 that will flush all the MAC addresses learned in the VPLS
from all the other PWs but the PWs connected to MTU-s.
PE-2 further relays MAC flush messages to all other PE devices in the
full mesh. Same processing rule applies at all those PE devices: all
the MAC addresses are flushed but the ones learned on the PW to PE2.
For example, at PE-3 all of the MAC addresses learned from the PWs
connected to PE-1 and PE-4 are flushed and relearned subsequently.
Before the relearning happens flooding of unknown destination MAC
addresses takes place throughout the network. As the number of PE
devices in the full-mesh increases, the number of unaffected MAC
addresses flushed in a VPLS instance also increases, thus leading to
unnecessary flooding and relearning. With large number of VPLS
instances provisioned in the H-VPLS network topology the amount of
unnecessary flooding and relearning increases. An optimization is
required that will flush only the MAC addresses learned from the PW
connected to PE1 to minimize the relearning and flooding in the
network.
Further the forwarding on MAC Flush by PE-2 delays the over-all MAC
flush propagation time into the core PEs in full mesh. So it is
desirable to avoid MAC flush forwarding across multiple PEs as far as
possible and yet achieve the same desired MAC flushing action.
3.1.2. MAC Flush optimization for native Ethernet access
The analysis in section 3.1.1 applies also to the native Ethernet
access into a VPLS where one active and one or more standby endpoints
into two or more VPLS or H-VPLS PEs are being used. Example of these
kind of access are ITU-T G.8032 access rings or any proprietary
multi-chassis LAG emulations.
Dutta, et. al Expires November 20, 2012 [Page 7]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
Same as in the active/standby PWs case from the previous section,
upon failure of the active native Ethernet endpoint on PE-1 a MAC
Flush optimization is required to ensure that on PE-2, PE-3 and PE-4
only the MAC addresses learned from the PW connected to PE-1 are
being flushed.
3.2. Black holing issue in PBB-VPLS
In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as
infrastructure for one or more I-component instances. B-VPLS control
plane (LDP Signaling) replaces I-component control plane throughout
the MPLS core. This is raising an additional challenge related to
black hole avoidance in the I-component domain as described in this
section. Figure 2 describes the case of a CE device (node A) dual-
homed to two I-component instances located on two PBB-VPLS PEs (PE1
and PE2).
IP/MPLS Core
+--------------+
|PE2 |
+----+ |
|PBB | +-+ |
_ |VPLS|---|P| |
S/+----+ /+-+\ |PE3
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
+---+ A +----+ +-+ +----+ +---+
A |PE1 | B
| |
+--------------+
Figure 2: PBB Black holing Issue - CE Dual-Homing use case
The link between PE1 and CE A is active (marked with A) while the
link between CE A and PE2 is in Standby/Blocked status. In the
network diagram CMAC X is one of the MAC addresses located behind CE
A in the customer domain, CMAC Y is behind CE B and the BVPLS
instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2
with BMAC B2.
As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the
remote PEs participating in the IVPLS (for example, PE3) will learn
Dutta, et. al Expires November 20, 2012 [Page 8]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
the CMAC X associated with BMAC B1 on PE1. Under failure of the link
between CE A and PE1 and activation of link to PE2, the remote PEs
(for example, PE3) will black-hole the traffic destined for customer
MAC X to BMAC B1 until the aging timer expires or a packet flows from
X to Y through the PE B2. This may take a long time (default aging
timer is 5 minutes) and may affect a large number of flows across
multiple I-components.
A possible solution to this issue is to use the existing LDP MAC
Flush as specified in [RFC4762] to flush in the BVPLS domain the BMAC
associated with the PE where the failure occurred. This will
automatically flush the CMAC to BMAC association in the remote PEs.
This solution though has the disadvantage of producing a lot of
unnecessary MAC flush in the B-VPLS domain as there was no failure or
topology change affecting the Backbone domain.
A better solution is required to propagate the I-component events
through the backbone infrastructure (B-VPLS) in order to flush only
the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there
are no IVPLS control plane exchanges across the PBB backbone,
extensions to B-VPLS control plane are required to propagate the I-
component MAC Flush events across the B-VPLS.
4. Solution description
4.1. MAC Flush Optimization for VPLS resiliency
The basic principle of the optimized MAC flush mechanism is explained
with reference to Figure 1.
PE-1 would initiate MAC Flush towards the core on detection of
failure of primary spoke PW between MTU-S and PE-1 (or status change
from active to standby). This method is referred as PE initiated MAC
Flush throughout this document. The MAC Flush message would indicate
to receiving PEs to flush all MACs learned over the PW in the context
of the VPLS over which the MAC flush message is received. Each PE
device in the full mesh that receives the message identifies the VPLS
instance and its respective PW that terminates in PE-1 from the FEC
TLV received in the message. Thus the PE device flushes only the MAC
addresses learned from that PW connected to PE-1 minimizing the
required relearning and the flooding throughout the VPLS domain.
This section defines a generic MAC Flush Parameters TLV for LDP
[RFC5036]. Through out this document the MAC Flush Parameters TLV is
referred as MAC Flush TLV. A MAC Flush TLV carries information on the
desired action at the PE device receiving the message and is used for
Dutta, et. al Expires November 20, 2012 [Page 9]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
optimized MAC flushing in H-VPLS. The MAC Flush TLV can also be used
for [RFC4762] style of MAC Flush as explained in section 3.1.
4.1.1. MAC Flush Parameters TLV format
The MAC Flush Parameters TLV is described as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| MAC Flush Params TLV(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U and F bits are set to forward if unknown so that potential
intermediate VPLS PEs unaware of the new TLV can just propagate it
transparently. The MAC Flush Parameters TLV type is to be assigned by
IANA. The encoding of the TLV follows the standard LDP TLV encoding
in [RFC5036].
The TLV value field contains a one byte Flag field used as described
below. Further the TLV value may carry one or more sub-TLVs. Any sub-
TLV definition to the above TLV MUST address the actions in
combination with other existing sub-TLVs.
The detailed format for the Flags bit vector is described below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|N| MBZ | (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
1 Byte Flag field is mandatory. The following flags are defined:
C flag, used to indicate the context of the PBB-VPLS component in
which MAC flush is required. For PBB-VPLS there are two contexts of
MAC flushing - The Backbone VPLS (B-component VPLS) and Customer
VPLS (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush
Dutta, et. al Expires November 20, 2012 [Page 10]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
for the B-VPLS is required. C flag MUST be set (C=1) when the MAC
Flush for I-VPLS is required. In the regular H-VPLS case the C flag
must be ZERO (C=0) to indicate the flush applies to the current
VPLS context.
N flag, used to indicate whether a positive (N=0, Flush-all-but-
mine) or negative (N=1 Flush-all-from-me) MAC Flush is required.
The source (mine/me) is defined either as the PW associated with
the LDP session on which the LDP MAC Withdraw was received or with
the BMAC(s) listed in the BMAC Sub-TLV. For the optimized MAC Flush
procedure described in this section the flag must be set (N=1).
Detailed usage in the context of PBB-VPLS is explained in section
4.2.
MBZ flags, the rest of the flags should be set to zero on
transmission and ignored on reception.
The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC
Flush message in [RFC4762].
4.1.2. Application of MAC Flush TLV in Optimized MAC Flush
For optimized MAC flush, the MAC Flush TLV MAY be sent as in existing
LDP Address Withdraw Message with empty MAC List but from the core PE
on detection of failure of its local spoke PW. The N bit in TLV MUST
be set to 1. If the optimized MAC Flush procedure is used in a
Backbone VPLS or regular VPLS/H-VPLS context the C bit must be ZERO
(C=0). If it is used in an I-VPLS context the C bit must be set (C=
1). See section 4.2 for PBB-VPLS details.
Note that if MAC Flush TLV is not understood by a receiver (i.e. a
legacy PE) then it may result in undesired action. For example if a
MAC Flush Parameters TLV is received with N=1 and receiver does not
understand that TLV then it would result in flushing of all MACs
learned in the VSI except the ones learned over the PW.
To emulate the MAC flush initiation procedures defined in [RFC4762],
the PE-1 MAY send MAC Flush TLV as an OPTIONAL TLV in the MAC Flush
Message with N = 0. This would result in same flushing action at
receiving PE devices.
Dutta, et. al Expires November 20, 2012 [Page 11]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
4.1.3. MAC Flush TLV Processing Rules for regular H-VPLS
This section describes the processing rules of MAC Flush TLV that
SHOULD be followed in the context of MAC flush procedures in an H-
VPLS.
For optimized MAC Flush a multi-homing PE initiates MAC flush message
towards the other related VPLS PEs when it detects a transition
(failure or to standby) in its active spoke PW. In such case the MAC
Flush TLV MUST be sent with N= 1. A PE device receiving the MAC Flush
TLV SHOULD follow the same processing rules as described in this
section.
Note that if MS-PW is used in VPLS then a MAC flush message is
processed only at the T-PE nodes since S-PE(s) traversed by the MS-PW
propagate MAC flush messages without any action. In this section, a
PE device signifies only T-PE in MS-PW case unless specified
otherwise.
When a PE device receives a MAC Flush TLV with N = 1, it SHOULD flush
all the MAC addresses learned from the PW in the VPLS in the context
on which the MAC Flush message is received.
If a MAC Flush TLV is received with N = 0 in the MAC flush message
then the receiving PE SHOULD flush the MAC addresses learned from all
PWs in the VPLS instance except the ones learned over the PW on which
the message is received.
If a PE device receives a MAC flush with the MAC Flush TLV option and
a valid MAC address list, it SHOULD ignore the option and deal with
MAC addresses explicitly as per [RFC4762].
If a PE device that doesn't support MAC Flush TLV receives a MAC
flush message with this option, it MUST ignore the option and follow
the processing rules as per [RFC4762]. However if MAC Flush
Parameters TLV was sent with N = 1 then it may result in wrong
flushing action (Positive MAC Flush).
4.1.4. Optimized MAC Flush Procedures
This section explains the optimized MAC flush procedure in the
scenario in Figure 1. When the primary spoke PW transition (failure
or standby transition) is detected by PE-1, it may send MAC flush
messages to PE-2, PE-3 and PE-4 with MAC Flush TLV and N = 1. Upon
receipt of the MAC flush message, PE-2 identifies the VPLS instance
that requires MAC flush from the FEC element in the FEC TLV. On
receiving N=1, PE-2 removes all MAC addresses learned from that PW
Dutta, et. al Expires November 20, 2012 [Page 12]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
over which the message is received. Same action is followed by PE-3
and PE-4.
Figure 3 shows another redundant H-VPLS topology to protect against
failure of MTU-s device. Provider RSTP may be used as selection
algorithm for active and backup PWs in order to maintain the
connectivity between MTU devices and PE devices at the edge. It is
assumed that PE devices can detect failure on PWs in either direction
through OAM mechanisms such as VCCV procedures for instance.
MTU-1================PE-1===============PE-3
|| || \ /||
|| Redundancy || \ / ||
|| Provider RSTP || Full-Mesh . ||
|| || / \ ||
|| || / \||
MTU-2----------------PE-2===============PE-4
Backup PW
Figure 3: Redundancy with Provider RSTP
MTU-1, MTU-2, PE-1 and PE-2 participate in provider RSTP. By
configuration in RSTP it is ensured that the PW between MTU-1 and PE-
1 is active and the PW between MTU-2 and PE-2 is blocked (made
backup) at MTU-2 end. When the active PW failure is detected by RSTP,
it activates the PW between MTU-2 and PE-2. When PE-1 detects the
failing PW to MTU-1, it may trigger MAC flush into the full mesh
with MAC Flush TLV that carries N=1. Other PE devices in the full
mesh that receive the MAC flush message identify their respective PWs
terminating on PE-1 and flush all the MAC addresses learned from it.
By default, MTU-2 should still trigger MAC flush as currently defined
in [RFC4762] after the backup PW is made active by RSTP. Mechanisms
to prevent two copies of MAC withdraws to be sent in such scenarios
is out of scope of this document.
[RFC4762] describes multi-domain VPLS service where fully meshed VPLS
networks (domains) are connected together by a single spoke PW per
VPLS service between the VPLS "border" PE devices. To provide
redundancy against failure of the inter-domain spoke, full mesh of
inter-domain spokes can be setup between border PE devices and
provider RSTP may be used for selection of the active inter-domain
Dutta, et. al Expires November 20, 2012 [Page 13]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
spoke. In case of inter-domain spoke PW failure, PE initiated MAC
withdrawal may be used for optimized MAC flushing within individual
domains.
Further, the procedures are applicable with any native Ethernet
access topologies multi-homed to two or more VPLS PEs. The text in
section 4.1 applies for the native Ethernet case where active/standby
PWs are replaced with the active/standby Ethernet endpoints. An
optimized MAC Flush message can be generated by the VPLS-PE that
detects the failure in the primary Ethernet access.
4.2. LDP MAC Withdraw Extensions for PBB-VPLS
The use of Address Withdraw message with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result
of a topology change (e.g. failure of a primary link of a VPLS PE and
implicitly the activation of an alternate link in a dual-homing use
case). These existing procedures apply individually to B-VPLS and I-
component domains.
When it comes to reflecting topology changes in access networks
connected to I-component across the B-VPLS domain certain additions
should be considered as described below.
MAC Switching in PBB is based on the mapping of Customer MACs (CMACs)
to Backbone MAC(s) (BMACs). A topology change in the access (I-
domain) should just invoke the flushing of CMAC entries in PBB PEs'
FIB(s) associated with the I-component(s) impacted by the failure.
There is a need to indicate the PBB PE (BMAC source) that originated
the MAC Flush message to selectively flush only the MACs that are
affected.
These goals can be achieved by adding a new MAC Flush Parameters TLV
in the LDP Address Withdraw message to indicate the particular
domain(s) requiring MAC flush. On the other end, the receiving PEs
may use the information from the new TLV to flush only the related
FIB entry/entries in the I-component instance(s).
The following sub-TLVs MUST be included in the MAC Flush Parameters
TLV if the C-flag is set to 1:
- PBB BMAC List sub-TLV:
Dutta, et. al Expires November 20, 2012 [Page 14]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
Type: 0x01
Length: value length in octets. At least one BMAC address must be
present in the list.
Value: one or a list of 48 bits BMAC addresses. These are the source
BMAC addresses associated with the B-VPLS instance that originated
the MAC Withdraw message. It will be used to identify the CMAC(s)
mapped to the BMAC(s) listed in the sub-TLV.
- PBB ISID List sub-TLV:
Type: 0x02,
Length: value length in octets. Zero indicates an empty ISID list. An
empty ISID list means that the flush applies to all the ISIDs mapped
to the B-VPLS indicated by the FEC TLV.
Value: one or a list of 24 bits ISIDs that represent the I-component
FIB(s) where the MAC Flush needs to take place.
4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS
The following steps describe the details of the processing for the
related LDP Address Withdraw message:
. The LDP MAC Withdraw Message, including the MAC Flush Parameters
TLV is initiated by the PBB PE(s) experiencing a Topology Change
event in one or multiple customer I-component(s).
o The flags are set accordingly to indicate the type of MAC
Flush required for this event: N=0 (Flush-all-but-mine),
C=1 (Flush only CMAC FIBs).
o The PBB Sub-TLVs (BMAC and ISID Lists) are included
according to the context of topology change.
. On reception of the LDP Address Withdrawal message, the B-VPLS
instances corresponding to the FEC TLV in the message must
interpret the content of MAC Flush Parameters TLV. If the C-bit is
set to 1 then Backbone Core Bridges (BCB) in the PBB-VPLS SHOULD
NOT flush their BMAC FIBs. The B-VPLS control plane SHOULD
propagate the MAC Flush following the split-horizon grouping and
the established B-VPLS topology.
. The usage and processing rules of MAC Flush Parameters TLV in the
context of Backbone Edge Bridges (BEB) is as follows:
Dutta, et. al Expires November 20, 2012 [Page 15]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
o The PBB ISID List is used to determine the particular ISID
FIBs (I-VPLS) that need to be flushed. If the ISID List is
empty then all the ISID FIBs associated with the receiving
B-VPLS SHOULD be flushed.
o The PBB BMAC List is used to identify from the ISID FIBs to
in the previous step to selectively flush BMAC to CMAC
associations depending on the N flag specified below.
. Next, depending on the N flag value the following actions apply:
o N=0, all the CMACs in the selected ISID FIBs SHOULD be
flushed with the exception of the resulted CMAC list from
the BMAC List mentioned in the message. ("Flush all but the
CMACs associated with the BMAC(s) in the BMAC List Sub-TLV
from the FIBs associated with the ISID list").
o N=1, the resulted CMAC list SHOULD be flushed ("Flush all
the CMACs associated with the BMAC(s) in the BMAC List Sub-
TLV from the FIBs associated with the ISID list").
4.2.3 Applicability of MAC Flush Parameters TLV
If MAC Flush Parameters TLV is received by a BEB in a PBB-VPLS
that does not understand the TLV then it may result in undesirable
MAC flushing action. It is RECOMMENDED that all PE devices
participating in PBB-VPLS support MAC Flush Parameters TLV.
The MAC Flush Parameters TLV is also applicable to regular VPLS
context as well. To achieve negative MAC Flush (flush-all-from-me) in
regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded
with C=0 and N = 1 without inclusion of any Sub-TLVs. Negative MAC
flush is highly desirable in scenarios when VPLS access redundancy is
provided by Ethernet Ring Protection as specified in ITU-T G.8032
specification etc.
5. Security Considerations
Control plane aspects:
- LDP security (authentication) methods as described in [RFC5036] is
applicable here. Further this document implements security
considerations as in [RFC4447] and [RFC4762].
Data plane aspects:
Dutta, et. al Expires November 20, 2012 [Page 16]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
- This specification does not have any impact on the VPLS forwarding
plane.
6. IANA Considerations
The Type field in MAC Flush Parameters TLV is defined as 0x406 and is
subject to IANA approval.
7. Acknowledgments
The authors would like to thank the following people who have
provided valuable comments and feedback on the topics discussed in
this document: Marc Lasserre, Don Fedyk, Dimitri Papadimitriou, Jorge
Rabadan, Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim
Henderickx, Jorge Rabadan, Maarten Vissers and Daniel Cohn.
8. References
8.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[RFC5036] Andersson, L., et al. "LDP Specification", RFC5036, October
2007.
[RFC4447] Martini. and et al., "Pseudowire Setup and Maintenance
Using Label Distribution Protocol (LDP)", RFC 4447, April
2006.
8.2. Informative References
[PBB-VPLS Model] F. Balus, et Al. "Extensions to VPLS PE model for
Provider Backbone Bridging", draft-ietf-l2vpn-pbb-vpls-pe-
model-00.txt, May 2009 (work in progress)
[RFC4664] Andersson, L., et al. "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
Dutta, et. al Expires November 20, 2012 [Page 17]
Internet-Draft Optimized MAC Withdrawal in H-VPLS May 20, 2012
[802.1w] "IEEE Standard for Local and metropolitan area networks.
Common specifications Part 3: Media Access Control (MAC)
Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std
802.1w-2001.
Author's Addresses
Pranjal Kumar Dutta
Alcatel-Lucent
701 E Middlefield Road,
Mountain View, CA 94043
USA
Email: pranjal.dutta@alcatel-lucent.com
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Geraldine Calvignac
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange-ftgroup.com
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
Email: ostokes@extremenetworks.com
Dutta, et. al Expires November 20, 2012 [Page 18]