draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-01.txt 
L2VPN Working Group Pranjal Kumar Dutta L2VPN Working Group Pranjal Kumar Dutta
Marc Lasserre Marc Lasserre
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Standard Intended status: Standard
Expires: October 2009 Olen Stokes Expires: September 2010 Olen Stokes
Extreme Networks Extreme Networks
April 26, 2009 March 7, 2010
LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt draft-ietf-l2vpn-vpls-ldp-mac-opt-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 26, 2009. This Internet-Draft will expire on September 7, 2010.
Abstract Abstract
[RFC4762] describes a mechanism to remove or unlearn MAC addresses [RFC4762] describes a mechanism to remove or unlearn MAC addresses
that have been dynamically learned in a VPLS Instance for faster that have been dynamically learned in a VPLS Instance for faster
convergence on topology change. The procedure also removes the MAC convergence on topology change. The procedure also removes MAC
addresses in the VPLS that does not require relearning due to such addresses in the VPLS that do not require relearning due to such
topology change. This document defines an extension to MAC Address topology change. This document defines an extension to the MAC
Withdrawal procedure with empty MAC List [RFC4762], which enables a Address Withdrawal procedure with empty MAC List [RFC4762], which
Provider Edge(PE) device to remove only the MAC addresses that needs enables a Provider Edge(PE) device to remove only the MAC addresses
to be relearned. that needs to be relearned.
Conventions used in this document Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 19 skipping to change at page 3, line 19
created using a collection of one or more point-to-point pseudowires created using a collection of one or more point-to-point pseudowires
(PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh
topology provides a LAN segment or broadcast domain that is fully topology provides a LAN segment or broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses at the capable of learning and forwarding on Ethernet MAC addresses at the
PE devices. PE devices.
This VPLS full mesh core configuration can be augmented with This VPLS full mesh core configuration can be augmented with
additional non-meshed spoke nodes to provide a Hierarchical VPLS additional non-meshed spoke nodes to provide a Hierarchical VPLS
(H-VPLS) service[RFC4762]. (H-VPLS) service[RFC4762].
MAC Address Withdrawal mechanism is described in [RFC4762] to A MAC Address Withdrawal mechanism is described in [RFC4762] to
remove or unlearn MAC addresses for faster convergence on topology remove or unlearn MAC addresses for faster convergence on topology
change in dual-homed H-VPLS[RFC4762]. In dual-homed H-VPLS, an edge change in dual-homed H-VPLS[RFC4762]. In dual-homed H-VPLS, an edge
device termed as MTU-s is connected to two PE devices via primary device termed as MTU-s is connected to two PE devices via primary
spoke PW and backup spoke PW respectively. Such redundancy is spoke PW and backup spoke PW respectively. Such redundancy is
designed to protect against the failure of primary spoke PW or designed to protect against the failure of primary spoke PW or
primary PE device. When MTU-s switches over to backup PW, it is primary PE device. When the MTU-s switches over to the backup PW, it
required to flush the MAC addresses learned in the VPLS in upstream is required to flush the MAC addresses learned in the corresponding
PE devices participating in full mesh, to avoid black holing of VSI in peer PE devices participating in full mesh, to avoid black
frames to those addresses. Note that forced switchover to backup PW Holing of frames to those addresses. Note that forced switchover to
can be also performed at MTU-s administratively due to maintenance backup PW can be also performed at MTU-s administratively due to
activities on the primary spoke PW. maintenance activities on the primary spoke PW.
When backup PW is made active by MTU-s, it triggers LDP Address When the backup PW is made active by the MTU-s, it triggers LDP
Withdraw Message with list of MAC addresses to be flushed. The Address Withdraw Message with a list of MAC addresses to be flushed.
message is forwarded over the LDP session(s) associated with the The message is forwarded over the LDP session(s) associated with the
newly activated PW. In order to minimize the impact on LDP newly activated PW. In order to minimize the impact on LDP
convergence time when MAC List TLV contains a large number of MAC convergence time when a MAC List TLV contains a large number of MAC
addresses, it may be preferable to send a LDP Address Withdraw addresses, it may be preferable to send a LDP Address Withdraw
Message with an empty MAC List. Throughout this document the term Message with an empty MAC List. Throughout this document the term
MAC Flush Message is used to specify LDP Address Withdraw Message MAC Flush Message is used to specify LDP Address Withdraw Message
with empty MAC List described in [RFC4762] unless specified with empty MAC List described in [RFC4762] unless specified
otherwise. otherwise.
As per the processing rules in [RFC4762] a PE device on receiving As per the processing rules in [RFC4762] a PE device on receiving
a MAC flush message removes all MAC addresses associated with a MAC flush message removes all MAC addresses associated with
the specified VPLS instance (as indicated in the FEC TLV) except the the specified VPLS instance (as indicated in the FEC TLV) except the
MAC addresses learned over the newly activated PW. The PE device MAC addresses learned over the newly activated PW. The PE device
further triggers MAC flush message to each remote PE device further triggers a MAC flush message to each remote PE device
connected to it in the VPLS full mesh. connected to it in the VPLS full mesh.
This method of MAC flushing is modeled after Topology Change This method of MAC flushing is modeled after Topology Change
Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[802.1w]. Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[802.1w].
When a bridge switches from failed link to the backup link, the 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 bridge sends out a TCN message over the newly activated link. The
upstream bridge upon receiving this message flushes its entire MAC upstream bridge upon receiving this message flushes its entire MAC
addresses except the ones received over this link and sends the TCN 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 out of its other ports in that spanning tree instance. The
message is further relayed along the spanning tree by the other message is further relayed along the spanning tree by the other
bridges. bridges.
When a PE device in the full-mesh of H-VPLS receives a MAC flush When a PE device in the full-mesh of H-VPLS receives a MAC flush
message it also flushes the MAC addresses which are not affected message it also flushes MAC addresses which are not affected
due to topology change, thus leading to unnecessary flooding and due to topology change, thus leading to unnecessary flooding and
relearning. This document describes the problem and a solution to relearning. This document describes the problem and a solution to
optimize the MAC flush procedure in [RFC4762] so that flush only optimize the MAC flush procedure in [RFC4762] so it flushes only
the set of MAC addresses that require relearning when topology the set of MAC addresses that require relearning when topology
changes in H-VPLS. changes in H-VPLS.
[L2VPN-SIG] describes about inter-AS VPLS deployments models where [L2VPN-SIG] describes about inter-AS VPLS deployments models where
Multi-Segment PWs (MS-PW) may be used. The solution proposed in Multi-Segment PWs (MS-PW) may be used. The solution proposed in
this document is generic and is applicable to MS-PWs in H-VPLS. this document is generic and is applicable to MS-PWs in H-VPLS.
2. Problem Description 2. Problem Description
Figure.1 describes a dual-homed H-VPLS scenerio for a VPLS instance Figure.1 describes a dual-homed H-VPLS scenerio for a VPLS instance
skipping to change at page 5, line 34 skipping to change at page 5, line 34
Customer Site 2 \------| -- | | -- | Customer Site 2 \------| -- | | -- |
| / \ |------------------| / \ |-> | / \ |------------------| / \ |->
| \s / | | \S / | | \s / | | \S / |
| -- | | -- | | -- | | -- |
+--------+ +--------+ +--------+ +--------+
PE-2 PE-4 PE-2 PE-4
Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS 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 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 acting as the primary primary spoke PW is active at MTU-s, thus PE-1 is acting as the
device to reach the full mesh in the VPLS instance. The MAC 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 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 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 those MAC addresses on their respective mesh PWs terminating to
PE-1. PE-1.
When MTU-s switches to backup spoke PW and activates it, PE-2 When MTU-s switches to the backup spoke PW and activates it, PE-2
becomes the primary device to reach the full mesh core. Traffic becomes the active device to reach the full mesh core. Traffic
entering the H-VPLS from CE-1 and CE-2 is diverted by MTU-s to the entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to
backup spoke PW. For faster convergence MTU-s may desire to unlearn the backup spoke PW. For faster convergence MTU-s may desire to
or remove the MAC addresses that have been learned in the upstream unlearn or remove the MAC addresses that have been learned in the
VPLS full-mesh through PE-1. MTU-s may send MAC flush message to upstream VPLS full-mesh through PE-1. MTU-s may send a MAC flush
PE-2 once the backup PW has been made active. As per the processing message to PE-2 once the backup PW has been made active. As per the
rules defined in [RFC4762], PE-2 flushes the entire MAC addresses processing rules defined in [RFC4762], PE-2 flushes all of the MAC
learned in the VPLS from the PWs terminating at PE-1, PE-3 and PE-4 addresses learned in the VPLS from the PWs terminating at PE-1, PE-3
except the ones learned over the newly activated spoke PW. and PE-4.
In the H-VPLS core, PE devices are connected in full mesh unlike the In the H-VPLS core, PE devices are connected in full mesh unlike the
spanning tree connectivity in bridges. So the MAC addresses that spanning tree connectivity in bridges. So the MAC addresses that
require flushing and relearning at PE-2 are only the MAC addresses require flushing and relearning at PE-2 are only the MAC addresses
those have been learned on the PW connected to PE-1. those have been learned on the PW connected to PE-1.
PE-2 further relays MAC flush messages to all other PE devices in 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. the full mesh. Same processing rule applies at all those PE devices.
For example, at PE-3 the entire MAC addresses learned from the PWs 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. connected to PE-1 and PE-4 are flushed and relearned subsequently.
As the number of PE devices in the full-mesh increases, the number As the number of PE devices in the full-mesh increases, the number
of unaffected MAC addresses flushed in a VPLS instance also of unaffected MAC addresses flushed in a VPLS instance also
increases, thus leading to unnecessary flooding and relearning. With increases, thus leading to unnecessary flooding and relearning. With
large number of VPLS instances provisioned in the H-VPLS network large number of VPLS instances provisioned in the H-VPLS network
topology the amount of unnecessary flooding and relearning topology the amount of unnecessary flooding and relearning
increases. increases.
3. Optimized MAC Flush Mechanism 3. Optimized MAC Flush Mechanism
skipping to change at page 8, line 17 skipping to change at page 8, line 17
A PE-ID Element value is encoded as 1 octet field that specifies the A PE-ID Element value is encoded as 1 octet field that specifies the
element type, 1 octet field that identifies the length in octets of element type, 1 octet field that identifies the length in octets of
the element value, and a variable length field that is type the element value, and a variable length field that is type
dependent element value. dependent element value.
The PE-ID Element value encoding is: The PE-ID Element value encoding is:
PE-ID Element Type Length Value PE-ID Element Type Length Value
Type name Type name
FEC-128 specific 0x01 2 octets See below. FEC-128 specific 0x01 12 octets See below.
FEC-129 specific 0x02 Variable See below. FEC-129 specific 0x02 Variable See below.
The type of PE-ID Element depends on the type of FEC Element used to The type of PE-ID Element depends on the type of FEC Element used to
provision the respective PW. provision the respective PW.
[RFC4447] defines two types of FEC elements that may be used for [RFC4447] defines two types of FEC elements that may be used for
provisioning PWs - Pwid FEC (type 128) and the Generalized ID (GID) provisioning PWs - Pwid FEC (type 128) and the Generalized ID (GID)
FEC (type 129). FEC (type 129).
The Pwid FEC element includes a fixed-length 32 bit value called the The Pwid FEC element includes a fixed-length 32 bit value called the
skipping to change at page 10, line 32 skipping to change at page 10, line 32
VPLS as described in section 4. VPLS as described in section 4.
It is to note that for optimized MAC flush the PE-ID TLV carries It is to note that for optimized MAC flush the PE-ID TLV carries
sufficient information for identifying the VPLS instance and the sufficient information for identifying the VPLS instance and the
unique VSI Identifier. For backward compatibility with MAC flush unique VSI Identifier. For backward compatibility with MAC flush
procedures in [RFC4762] both FEC TLV and PE-ID TLV should be sent in procedures in [RFC4762] both FEC TLV and PE-ID TLV should be sent in
the MAC flush message. However the inclusion of the FEC-TLV should be the MAC flush message. However the inclusion of the FEC-TLV should be
based on what would be the desired effect should the PE-ID not be based on what would be the desired effect should the PE-ID not be
understood by the receiver. In cases where the desired action when understood by the receiver. In cases where the desired action when
the PE-ID is not understood would be to behave as described in the PE-ID is not understood would be to behave as described in
[RFC4762], then the FEC TLV SHOULD be included. In cases where the [RFC4762], then the FEC TLV SHOULD be always included. In cases
desired action when the PE-ID is not understood is to take no where the desired action when the PE-ID is not understood is no mac
action, then the FEC TLV SHOULD NOT be included. The PE-ID TLV flushing, then the FEC TLV SHOULD NOT be included. The PE-ID TLV
SHOULD carry the unique VSI identifier in the VPLS instance SHOULD carry the unique VSI identifier in the VPLS instance
(specified in the FEC TLV). The PE-ID TLV SHOULD be placed after the (specified in the FEC TLV). The PE-ID TLV SHOULD be placed after the
existing TLVs in MAC Flush message in [RFC4762]. existing TLVs in MAC Flush message in [RFC4762].
5.1 PE-ID TLV Processing Rules 5.1 PE-ID TLV Processing Rules
This section describes the processing rules of PE-ID TLV that SHOULD This section describes the processing rules of PE-ID TLV that SHOULD
be followed in the context of MAC flush procedures in an H-VPLS. be followed in the context of MAC flush procedures in an H-VPLS.
When an MTU-s triggers MAC flush after activation of backup spoke When an MTU-s triggers MAC flush after activation of backup spoke
PW, it MAY send the PE-ID TLV that identifies VSI in the formerly PW, it MAY send the PE-ID TLV that identifies VSI in the formerly
active PE device. There may be cases where a PE device in full mesh active PE device. There may be cases where a PE device in full mesh
initiates MAC flush torwards the core when it detects a spoke PW initiates MAC flush torwards the core when it detects a spoke PW
failure. In such a case the PE-ID TLV in MAC flush message failure. In such a case the PE-ID TLV in MAC flush message
MAY identify its own VSI in the VPLS instance. Irrespective of MAY identify its own VSI. Irrespective of whether it is the MTU-s or
whether it is the MTU-s or PE device that initiates the MAC flush, a PE device that initiates the MAC flush, a PE device receiving the
PE device receiving the PE-ID TLV SHOULD follow the same processing PE-ID TLV SHOULD follow the same processing rules as described in
rules as described in this section. this section.
If MS-PW signaled with GID Element is used in VPLS then a MAC flush Note that if MS-PW is used in VPLS then a MAC flush message is
message is processed only at the T-PE nodes. In this section, a PE processed only at the T-PE nodes since S-PE(s) traversed by the MS-
device signifies only T-PE in MS-PW case unless specified otherwise. 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 with PE-ID TLV, it SHOULD When a PE device receives a MAC flush with PE-ID TLV, it SHOULD
flush all the MAC addresses learned in the VPLS from the PW that flush all the MAC addresses learned from the PW that terminates in
terminates in the remote VSI identified by the PE-ID element. the remote VSI identified by the PE-ID element.
If a PE-ID element received in the MAC flush message identifies the If a PE-ID element received in the MAC flush message identifies the
local VSI, it SHOULD flush the MAC addresses learned from its local VSI, it SHOULD flush the MAC addresses learned from its
local spoke PW(s) in the VPLS instance. local spoke PW(s) in the VPLS instance.
If a PE device receives a MAC flush with the PE-ID TLV option If a PE device receives a MAC flush with the PE-ID TLV option
And a valid MAC address list, it SHOULD ignore the option and deal and a valid MAC address list, it SHOULD ignore the option and deal
with MAC addresses explicitly as per [RFC4762]. with MAC addresses explicitly as per [RFC4762].
If a PE device that doesn't support PE-ID TLV receives a MAC flush If a PE device that doesn't support PE-ID TLV receives a MAC flush
message with this option, it MUST ignore the option and follow the message with this option, it MUST ignore the option and follow the
processing rules as per [RFC4762]. processing rules as per [RFC4762].
5.2 Optimized MAC Flush Procedures 5.2 Optimized MAC Flush Procedures
This section explains the optimized MAC flush procedure in the This section explains the optimized MAC flush procedure in the
scenario in Figure.1. scenario in Figure.1.
When the backup PW is activated by MTU-s, it may send MAC flush When the backup PW is activated by MTU-s, it may send MAC flush
message to PE-2 with the optional PE-ID TLV. The PE-ID element message to PE-2 with the FEC TLV and the optional PE-ID TLV. The
carries the VSI identifier in PE-1 for the VPLS. Upon receipt of the PE-ID element carries the VSI identifier in PE-1 for the VPLS. Upon
MAC flush message, PE-2 identifies the VPLS instance that requires receipt of the MAC flush message, PE-2 identifies the VPLS instance
MAC flush from the FEC element in the FEC TLV. From the PE-ID TLV, that requires MAC flush from the FEC element in the FEC TLV. From
PE-2 identifies the PW in the VPLS that terminates in PE-1. PE-2 the PE-ID TLV, PE-2 identifies the PW in the VPLS that terminates in
removes all MAC addresses learned from that PW. PE-1. PE-2 removes all MAC addresses learned from that PW.
PE-2 relays MAC flush messages with the received PE-ID to all its PE-2 relays MAC flush messages with the received PE-ID to all its
peer PE devices. When the message is received at PE-3, it identifies peer PE devices. When the message is received at PE-3, it identifies
the PW that terminates in the remote VSI in PE-1. PE-3 removes all the PW that terminates in the remote VSI in PE-1. PE-3 removes all
MAC addresses learned on the PW that terminated in PE1. MAC addresses learned on the PW that terminated in PE1.
There may be redundancy scenerios where a PE device in the full mesh There may be redundancy scenerios where a PE device in the full mesh
may be required to initiate optimized MAC Address Withdrawal. may be required to initiate optimized MAC Address Withdrawal.
Figure 5. shows a redundant H-VPLS topology to protect against Figure 5. shows a redundant H-VPLS topology to protect against
failure of MTU-s device. Provider RSTP may be used as selection failure of MTU-s device. Provider RSTP may be used as selection
skipping to change at page 16, line 13 skipping to change at page 16, line 13
Reconfiguration", IEEE Std 802.1w-2001. Reconfiguration", IEEE Std 802.1w-2001.
Author's Addresses Author's Addresses
Pranjal Kumar Dutta Pranjal Kumar Dutta
Alcatel-Lucent Alcatel-Lucent
701 E Middlefield Road, 701 E Middlefield Road,
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: pdutta@alcatel-lucent.com Email: pranjal.dutta@alcatel-lucent.com
Marc Lasserre Marc Lasserre
Alcatel-Lucent Alcatel-Lucent
Email: marc.lasserre@alcatel-lucent.com Email: marc.lasserre@alcatel-lucent.com
Olen Stokes Olen Stokes
Extreme Networks Extreme Networks
PO Box 14129 PO Box 14129
RTP, NC 27709 RTP, NC 27709
USA USA
Email: ostokes@extremenetworks.com Email: ostokes@extremenetworks.com
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
64 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/