draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt 
L2VPN Working Group Pranjal Kumar Dutta L2VPN Working Group Pranjal Kumar Dutta
Florin Balus Florin Balus
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Standard Intended status: Standard
Expires: January 21, 2011 Olen Stokes Expires: December 16, 2011 Olen Stokes
Extreme Networks Extreme Networks
Geraldine Calvignac Geraldine Calvignac
France Telecom France Telecom
October 25, 2010 June 23, 2011
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-03.txt draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 25, 2011. This Internet-Draft will expire on December 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 37
Additional extensions to [RFC4762] MAC Withdrawal procedures are Additional extensions to [RFC4762] MAC Withdrawal procedures are
specified to provide optimized MAC flushing for the PBB-VPLS specified to provide optimized MAC flushing for the PBB-VPLS
specified in [PBB-VPLS Model]. specified in [PBB-VPLS Model].
Table of Contents Table of Contents
1.1. Conventions used in this document.........................3 1.1. Conventions used in this document.........................3
2. Introduction...................................................3 2. Introduction...................................................3
3. Problem Description............................................5 3. Problem Description............................................5
3.1. MAC Flush in regular H-VPLS...............................5 3.1. MAC Flush optimization in VPLS resiliency.................5
3.2. Black holing issue in PBB-VPLS............................7 3.1.1. MAC Flush optimization for regular H-VPLS............5
4. Solution description...........................................8 3.1.2. MAC Flush optimization for native Ethernet access....7
4.1. MAC Flush Optimization for regular H-VPLS.................8 3.2. Black holing issue in PBB-VPLS............................8
4.1.1. PE-ID TLV Format.....................................8 4. Solution description...........................................9
4.1.2. Application of PE-ID TLV in Optimized MAC Flush.....11 4.1. MAC Flush Optimization for VPLS resiliency................9
4.1.3. PE-ID TLV Processing Rules..........................11 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.1.4. Optimized MAC Flush Procedures......................12
4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................14 4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................14
4.2.1. MAC Flush Parameters TLV format.....................14 4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS.........15
4.2.2. MAC Flush Parameters TLV Processing Rules...........16 5. Security Considerations.......................................16
5. Security Considerations.......................................17 6. IANA Considerations...........................................17
6. IANA Considerations...........................................18 7. Acknowledgments...............................................17
7. Acknowledgments...............................................18 8. References....................................................17
8. References....................................................18 8.1. Normative References.....................................17
8.1. Normative References.....................................18 8.2. Informative References...................................17
8.2. Informative References...................................18 Author's Addresses...............................................18
Author's Addresses...............................................19
1.1. Conventions used in this document 1.1. Conventions used in this document
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 RFC-2119. document are to be interpreted as described in RFC-2119.
This document uses the terminology defined in [PBB-VPLS Model], This document uses the terminology defined in [PBB-VPLS Model],
[RFC5036], [RFC4447] and [RFC4762]. Throughout this document VPLS [RFC5036], [RFC4447] and [RFC4762]. Throughout this document VPLS
means the emulated bridged LAN service offered to a customer. H-VPLS means the emulated bridged LAN service offered to a customer. H-VPLS
skipping to change at page 3, line 30 skipping to change at page 3, line 31
offering the VPLS [RFC4762]. The terms spoke node and MTU-s in H-VPLS offering the VPLS [RFC4762]. The terms spoke node and MTU-s in H-VPLS
are used interchangeably. are used interchangeably.
2. Introduction 2. Introduction
A method of Virtual Private LAN Service (VPLS), also known as A method of Virtual Private LAN Service (VPLS), also known as
Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is
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 Ethernet MAC addresses at the PE
PE devices. 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 (H- additional non-meshed spoke nodes to provide a Hierarchical VPLS (H-
VPLS) service [RFC4762]. 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 [PBB-VPLS Model] describes how Provider Backbone Bridging (PBB) can
be integrated with VPLS to allow for useful PBB capabilities while be integrated with VPLS to benefit from PBB capabilities while
continuing to avoid the use of MSTP in the backbone. The combined continuing to avoid the use of MSTP in the backbone. The combined
solution referred to as PBB-VPLS results in better scalability in 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 terms of number of service instances, PWs and customer MACs (CMACs)
handled in the VPLS PEs. that need to be handled in the VPLS PEs.
A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762] A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762]
to remove or unlearn MAC addresses for faster convergence on topology to remove or unlearn MAC addresses for faster convergence on a
change in resilient H-VPLS topologies. topology change in resilient H-VPLS topologies.
An example of usage of the MAC Flush mechanism is the dual-homed An example of the usage of the MAC Flush mechanism is a dual-homed
H-VPLS where an edge device termed as MTU-s is connected to two PE 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 devices via a primary spoke PW and a backup spoke PW, respectively.
redundancy is designed to protect against the failure of primary Such redundancy is designed to protect against the failure of the
spoke PW or primary PE device. When the MTU-s switches over to the primary spoke PW or primary PE device.
backup PW, it is required to flush the MAC addresses learned in the
corresponding VSI in peer PE devices participating in full mesh, to When the MTU-s switches over to the backup PW, it is useful to flush
avoid black holing of frames to those addresses. Note that forced the MAC addresses learned in the corresponding VSI in the peer PE
switchover to backup PW can be also performed at MTU-s devices participating in the full mesh to avoid black holing of
administratively due to maintenance activities on the primary spoke frames to those addresses. Note that a forced switchover to the
PW. When the backup PW is made active by the MTU-s, it triggers LDP backup PW can be also performed at MTU-s administratively due to
Address Withdraw Message with a list of MAC addresses to be flushed. maintenance activities on the primary spoke PW. When the backup PW is
The message is forwarded over the LDP session(s) associated with the made active by the MTU-s it triggers an LDP Address Withdraw Message
newly activated PW. In order to minimize the impact on LDP with a list of MAC addresses to be flushed. The message is forwarded
convergence time and scalability when a MAC List TLV contains a large over the LDP session(s) associated with the newly activated PW. In
number of MAC addresses, many implementations use a LDP Address order to minimize the impact on LDP convergence time and scalability
Withdraw Message with an empty MAC List. Throughout this document the when a MAC List TLV contains a large number of MAC addresses, many
term MAC Flush Message is used to specify LDP Address Withdraw implementations use an LDP Address Withdraw Message with an empty MAC
Message with empty MAC List described in [RFC4762] unless specified List. Throughout this document the term MAC Flush Message is used to
otherwise. specify an LDP Address Withdraw Message with an empty MAC List
described in [RFC4762] unless specified otherwise.
As per the MAC Address Withdrawal processing rules in [RFC4762] a PE As per the MAC Address Withdrawal processing rules in [RFC4762] a PE
device on receiving a MAC flush message removes all MAC addresses device on receiving a MAC flush message removes all MAC addresses
associated with the specified VPLS instance (as indicated in the FEC associated with the specified VPLS instance (as indicated in the FEC
TLV) except the MAC addresses learned over the newly activated PW. TLV) except for the MAC addresses learned over the newly activated
The PE device further triggers a MAC flush message to each remote PE PW. The PE device further triggers a MAC flush message to each remote
device connected to it in the VPLS full mesh. PE device 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 a 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. When a PE device in the full-mesh of H-VPLS receives a MAC 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 flush 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 it flushes only the optimize the MAC flush procedure in [RFC4762] so it flushes the
set of MAC addresses that require relearning when topology changes in minimal set of MAC addresses that require relearning when the
H-VPLS. The solution proposed in this document is generic and is topology changes in H-VPLS. The solution proposed in this document is
applicable when MS-PWs are used in interconnecting PE devices in generic and is applicable when MS-PWs are used in interconnecting PE
H-VPLS. devices in H-VPLS.
[PBB-VPLS Model] describes how PBB can be integrated with VPLS to [PBB-VPLS Model] describes how PBB can be integrated with VPLS to
allow for useful PBB capabilities while continuing to avoid the use benefit from PBB capabilities while continuing to avoid the use of
of MSTP in the backbone. The combined solution referred as PBB-VPLS MSTP in the backbone. The combined solution referred as PBB-VPLS
results in better scalability in terms of number of service results in better scalability in terms of number of service
instances, PWs and C-MACs that need to be handled in the VPLS PEs. instances, PWs and CMACs that need to be handled in the VPLS PEs.
This document describes also extensions to LDP MAC Flush procedures This document also describes extensions to LDP MAC Flush procedures
described in [RFC4762] required to build desirable capabilities to described in [RFC4762] required to build desirable capabilities in a
PBB-VPLS solution. PBB-VPLS solution.
Section 3 covers the problem space. Section 4 describes the solution Section 3 covers the problem space. Section 4 describes the solution
and the required TLV extensions. and the required TLV extensions.
3. Problem Description 3. Problem Description
3.1. MAC Flush in regular H-VPLS 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 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 where the problem with the existing MAC flush method in [RFC4762] is
explained. explained.
PE-1 PE-3 PE-1 PE-3
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
| -- | | -- | | -- | | -- |
Customer Site 1 | / \ |------------------| / \ |-> Customer Site 1 | / \ |------------------| / \ |->
skipping to change at page 6, line 18 skipping to change at page 7, line 4
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 is acting as 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 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 PE-1. those MAC addresses on their respective mesh PWs terminating to PE-1.
When MTU-s switches to the backup spoke PW and activates it, PE-2 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 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 entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to
the backup spoke PW. For faster convergence MTU-s may desire to the spoke PW to PE-2. To avoid traffic black holing the MAC addresses
unlearn or remove the MAC addresses that have been learned in the that have been learned in the upstream VPLS full-mesh through PE-1
upstream VPLS full-mesh through PE-1. MTU-s may send a MAC flush must be relearned or removed from the MAC FIBs of PE-2, PE-3 and PE-
message to PE-2 once the backup PW has been made active. As per the 4.
processing rules defined in [RFC4762], PE-2 flushes the MAC addresses
learned in the VPLS from the PWs terminating at PE-1, PE-3 and PE-4.
In the H-VPLS core, PE devices are connected in full mesh unlike the As per the processing rules defined in [RFC4762], on activation of
spanning tree connectivity in bridges. So the MAC addresses that the backup PW from MTU-s, a MAC flush message will be sent by MTU-s
require flushing and relearning at PE-2 are only the MAC addresses to PE-2 that will flush all the MAC addresses learned in the VPLS
those have been learned on the PW connected to PE-1. from all the other PWs except the PWs connected to MTU-s.
PE-2 further relays MAC flush messages to all other PE devices in the 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. For full mesh. Same processing rule applies at all those PE devices: all
example, at PE-3 all of the MAC addresses learned from the PWs the MAC addresses are flushed except the ones learned on the PW to
connected to PE-1 and PE-4 are flushed and relearned subsequently. As PE2. For example, at PE-3 all of the MAC addresses learned from the
the number of PE devices in the full-mesh increases, the number of 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, unaffected MAC addresses flushed in a VPLS instance also increases,
thus leading to unnecessary flooding and relearning. With large thus leading to unnecessary flooding and relearning. With a large
number of VPLS instances provisioned in the H-VPLS network topology number of VPLS instances provisioned in the H-VPLS network topology
the amount of unnecessary flooding and relearning increases. 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 PE-1 to minimize the relearning and
flooding in the network.
Further the forwarding of the MAC Flush by PE-2 delays the overall
MAC flush propagation time into the core PEs in the 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 backup endpoints
into two or more VPLS or H-VPLS PEs are being used. Examples of these
are [G.8032v2] access rings or any proprietary multi-chassis LAG
emulations.
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 3.2. Black holing issue in PBB-VPLS
In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as In a PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as the
infrastructure for one or more I-component instances. B-VPLS control infrastructure for one or more I-component instances. B-VPLS control
plane (LDP Signaling) replaces I-component control plane throughout plane (LDP Signaling) replaces the I-component control plane
the MPLS core. This is raising an additional challenge related to throughout the MPLS core. This raises an additional challenge related
black hole avoidance in the I-component domain as described in this to black hole avoidance in the I-component domain as described in
section. Figure 2 describes the case of a CE device (node A) dual- this section. Figure 2 describes the case of a CE device (node A)
homed to two I-component instances located on two PBB-VPLS PEs (PE1 dual-homed to two I-component instances located on two PBB-VPLS PEs
and PE2). (PE1 and PE2).
IP/MPLS Core IP/MPLS Core
+--------------+ +--------------+
|PE2 | |PE2 |
+----+ | +----+ |
|PBB | +-+ | |PBB | +-+ |
_ |VPLS|---|P| | _ |VPLS|---|P| |
S/+----+ /+-+\ |PE3 B/+----+ /+-+\ |PE3
/ +----+ / \+----+ / +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+ +---+/ |PBB |/ +-+ |PBB | +---+
CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
+---+ A +----+ +-+ +----+ +---+ +---+ A +----+ +-+ +----+ +---+
A |PE1 | B A |PE1 | B
| | | |
+--------------+ +--------------+
Figure 2: PBB Black holing Issue - CE Dual-Homing use case 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 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 link between CE A and PE2 is in Backup/Blocked status. In the network
network diagram CMAC X is one of the MAC addresses located behind CE diagram CMAC X is one of the MAC addresses located behind CE A in the
A in the customer domain, CMAC Y is behind CE B and the BVPLS customer domain, CMAC Y is behind CE B and the B-VPLS instances on
instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2 PE1 and PE2 are associated with backbone MAC (BMAC) B1 and BMAC B2,
with BMAC B2. respectively.
As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the As the packets flow from CMAC X to CMAC Y through PE1 with BMAC B1,
remote PEs participating in the IVPLS (for example, PE3) will learn the remote PEs participating in the I-VPLS (for example, PE3) will
the CMAC X associated with BMAC B1 on PE1. Under failure of the link learn the CMAC X associated with BMAC B1 on PE1. Under failure of the
between CE A and PE1 and activation of link to PE2, the remote PEs link between CE A and PE1, and with the activation of link to PE2,
(for example, PE3) will black-hole the traffic destined for customer the remote PEs (for example, PE3) will black hole the traffic
MAC X to BMAC B1 until the aging timer expires or a packet flows from destined to customer MAC X to BMAC B1 until the aging timer expires
X to Y through the PE B2. This may take a long time (default aging or a packet flows from X to Y through the PE2 with B2. This may take
timer is 5 minutes) and may affect a large number of flows across a long time (default aging timer is 5 minutes) and may affect a large
multiple I-components. number of flows across multiple I-components.
A possible solution to this issue is to use the existing LDP MAC 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 Flush as specified in [RFC4762] to flush in the B-VPLS domain the
associated with the PE where the failure occurred. This will BMAC associated with the PE where the failure occurred. This will
automatically flush the CMAC to BMAC association in the remote PEs. automatically flush the CMAC to BMAC association in the remote PEs.
This solution though has the disadvantage of producing a lot of 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 unnecessary MAC flushes in the B-VPLS domain as there was no failure
topology change affecting the Backbone domain. or topology change affecting the Backbone domain.
A better solution is required to propagate the I-component events A better solution is required to propagate the I-component events
through the backbone infrastructure (B-VPLS) in order to flush only 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 the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there
are no IVPLS control plane exchanges across the PBB backbone, are no I-VPLS control plane exchanges across the PBB backbone,
extensions to B-VPLS control plane are required to propagate the I- extensions to the B-VPLS control plane are required to propagate the
component MAC Flush events across the B-VPLS. I-component MAC Flush events across the B-VPLS.
4. Solution description 4. Solution description
4.1. MAC Flush Optimization for regular H-VPLS 4.1. MAC Flush Optimization for VPLS resiliency
The basic principle of the optimized MAC flush mechanism is explained The basic principle of the optimized MAC flush mechanism is explained
with reference to Figure 1. On switching over to the backup spoke PW with reference to Figure 1.
when MTU-s triggers MAC flush message to PE-2, it also communicates
the unique PW endpoint identifier (PE-ID) in PE-1, the formerly
active PE device. In VPLS a PW terminates on a Virtual Switching
Instance (VSI) in a PE device. The PE-ID is relayed in all the
subsequent MAC flush messages triggered by PE-2 to its peer PE
devices in the full mesh. Each PE device that receives the message
identifies the VPLS (From FEC TLV) and its respective PW that
terminates in PE-1 (from PE-ID). Thus the PE device flushes only the
MAC addresses learned from that PW connected to PE-1.
This section defines a PW Endpoint Identifier (PE-ID) TLV for LDP
[RFC5036]. The PE-ID TLV carries the unique identifier of a generic
PW endpoint.
4.1.1. PE-ID TLV Format
The encoding of PE-ID TLV follows standard LDP TLV encoding in
[RFC5036]. A PE-ID TLV contains a list of one or more PE-ID Elements.
Its encoding is:
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|0| PE-ID TLV (0x0405) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE-ID Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE-ID Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U (Unknown) bit of thus LDP TLV MUST be set to 1. If the PE-ID TLV is
not understood then it is ignored the receiving device.
F (Forward) MUST be set to 0. Since the LDP mechanism used here is
targeted, the TLV is not forwarded if it is not understood by the
receiving device.
The Type field MUST be set to 0x405 (subject to IANA approval). This
identifies the TLV type as PE-ID TLV.
Length field specifies the total length in octets of the Value in PE-
ID TLV.
PE-ID Element 1 to PE-ID Element n: there are several types of PE-ID
Elements. The PE-ID Element Encoding depends on the type of the PE-ID
Element. A PE-ID Element uniquely identifies a PW Endpoint.
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
the element value, and a variable length field that is type dependent
element value.
The PE-ID Element value encoding is: PE-1 would initiate a MAC Flush towards the core on detection of the
failure of the primary spoke PW between MTU-s and PE-1 (or status
change from active to standby). This method is referred to as a 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.
PE-ID name Type Length Value This section defines a generic MAC Flush Parameters TLV for LDP
[RFC5036]. Throughout this document the MAC Flush Parameters TLV is
referred to as a MAC Flush TLV. A MAC Flush TLV carries information
on the desired action at the PE device receiving the message and is
used for optimized MAC flushing in H-VPLS. The MAC Flush TLV is
backward compatible and can be used for [RFC4762] style of MAC Flush
as explained in section 3.1.
FEC-128 specific 0x01 12 octets See below. 4.1.1. MAC Flush Parameters TLV format
FEC-129 specific 0x02 Variable See below. The MAC Flush Parameters TLV is described as below:
The type of PE-ID Element depends on the type of FEC Element used to 0 1 2 3
provision the respective PW. [RFC4447] defines two types of FEC 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
elements that may be used for provisioning PWs - Pwid FEC (type 128) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and the Generalized ID (GID) FEC (type 129). The Pwid FEC element |1|1| MAC Flush Params TLV(TBD) | Length |
includes a fixed-length 32 bit value called the PWid. The same PWid +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
value must be configured on the local and remote PE prior to PW | Flags | Sub-TLV Type | Sub-TLV Length |
setup. The GID FEC element includes TLV fields for attachment +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
individual identifiers (AII) that, in conjunction with an attachment | Sub-TLV Variable Length Value |
group identifier (AGI), serve as PW endpoint identifiers. The | " |
endpoint identifier on the local PE (denoted as <AGI, source AII or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SAII>) is called the source attachment identifier (SAI) and the
endpoint identifier on the remote PE (denoted as <AGI, target AII or
TAII>) is called the target attachment identifier (TAI). The SAI and
TAI can be distinct values. This is useful for provisioning models
where the local PE (with a particular SAI) does not know and must
somehow learn (e.g. via MP-BGP auto-discovery) of remote TAI values
prior to launching PW setup messages towards the remote PE.
FEC-128 specific PE-ID Element 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].
This sub-type is to be used to identify a PW endpoint only if Pwid The TLV value field contains a one byte Flag field used as described
FEC Element is used for signaling the PW. The encoding of this PE-ID below. Further, the TLV value may carry one or more sub-TLVs. Any
element is as follows: 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:
| 0x01 | Length | PW type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PW type: The PW Type value from PWid FEC element. 0 1 2 3 4 5 6 7
PW ID: The PW ID value from the Pwid FEC element. +-+-+-+-+-+-+-+-+
Endpoint Address: 32-bit LSR-ID from the LDP-ID used in LDP |C|N| MBZ | (MBZ = MUST Be Zero)
signaling Session by a PW endpoint.
FEC-129 specific PE-ID element +-+-+-+-+-+-+-+-+
This sub-type is to be used to indentify a PW endpoint only if GID 1 Byte Flag field is mandatory. The following flags are defined :
FEC Element is used for signaling the PW. The encoding of this PE-ID
element is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C flag, used to indicate the context of the PBB-VPLS component in
| 0x02 | Length | PW type | which MAC flush is required. For PBB-VPLS there are two contexts of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC flushing - The Backbone VPLS (B-component VPLS) and Customer
| AGI TLV | VPLS (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for the B-VPLS is required. C flag MUST be set (C=1) when the MAC
| AII TLV | 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.
PW type: The PW Type value from GID FEC element. 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 List Sub-TLV. For the optimized MAC
Flush procedure described in this section the flag must be set
(N=1).
PW ID: The PW ID value from the GID FEC element. Detailed usage in the context of PBB-VPLS is explained in section
4.2.
AGI TLV: The AGI from the corresponding GID Element MBZ flags, the rest of the flags MUST be set to zero on
transmission and ignored on reception.
AII TLV: The AII associated with the PW endpoint. 4.1.2. Application of MAC Flush TLV in Optimized MAC Flush
4.1.2. Application of PE-ID TLV in Optimized MAC Flush For the optimized MAC flush, the MAC Flush TLV MAY be sent as in the
existing LDP Address Withdraw Message with an empty MAC List but from
the core PE on detection of failure of its local spoke PW. The N bit
in the 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.
For optimized MAC flush, the PE-ID TLV MAY be sent as an OPTIONAL Note that if a MAC Flush TLV is not understood by a receiver then it
parameter in existing LDP Address Withdraw Message with empty MAC may result in undesired action. For example if a MAC Flush Parameters
List. The PE-ID TLV carries the unique PW endpoint identifier in a TLV is received with N=1 and receiver does not understand that TLV
VPLS as described in section 4. then it would result in flushing of all MACs learned in the VSI
except the ones learned over the PW. The MAC Flush TLV SHOULD be
placed after the existing TLVs in MAC Flush message in [RFC4762].
It is to note that for optimized MAC flush the PE-ID TLV carries For backward compatibility of MAC flush initiation procedures as
sufficient information for identifying the VPLS instance and the defined in [RFC4762], the PE-1 MAY send a MAC Flush TLV as an
unique VSI Identifier. For backward compatibility with MAC flush OPTIONAL TLV in the MAC Flush Message with N = 0. This would result
procedures in [RFC4762] both FEC TLV and PE-ID TLV should be sent in in same flushing action at the receiving PE devices as desired in
the MAC flush message. However the inclusion of the FEC-TLV should be [RFC4762].
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
the PE-ID is not understood would be to behave as described in
[RFC4762], then the FEC TLV SHOULD be always included. In cases
where the desired action when the PE-ID is not understood is no mac
flushing, then the FEC TLV SHOULD NOT be included. The PE-ID TLV
SHOULD carry the unique VSI identifier in the VPLS instance
(specified in the FEC TLV). The PE-ID TLV SHOULD be placed after the
existing TLVs in MAC Flush message in [RFC4762].
4.1.3. PE-ID TLV Processing Rules 4.1.3. MAC Flush TLV Processing Rules for regular H-VPLS
This section describes the processing rules of PE-ID TLV that SHOULD This section describes the processing rules of a MAC Flush TLV that
be followed in the context of MAC flush procedures in an H-VPLS. SHOULD 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 PW, For optimized MAC Flush a multi-homing PE initiates a MAC flush
it MAY send the PE-ID TLV that identifies VSI in the formerly active message towards the other related VPLS PEs when it detects a
PE device. There may be cases where a PE device in full mesh transition (failure or to standby) in an active spoke PW. In such a
initiates MAC flush towards the core when it detects a spoke PW case the MAC Flush TLV MUST be sent with N = 1. A PE device receiving
failure. In such a case the PE-ID TLV in MAC flush message MAY the MAC Flush TLV SHOULD follow the same processing rules as
identify its own VSI. Irrespective of whether it is the MTU-s or PE described in this section.
device that initiates the MAC flush, a PE device receiving the PE-ID
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 Note that if MS-PW is used in the VPLS then a MAC flush message is
processed only at the T-PE nodes since S-PE(s) traversed by the MS-PW processed only at the T-PE nodes since the S-PE(s) traversed by the
propagate MAC flush messages without any action. In this section, a MS-PW propagate MAC flush messages without any action. In this
PE device signifies only T-PE in MS-PW case unless specified section, a PE device signifies only T-PE in the MS-PW case unless
otherwise. specified otherwise.
When a PE device receives a MAC flush with PE-ID TLV, it SHOULD flush When a PE device receives a MAC Flush TLV with N = 1, it SHOULD flush
all the MAC addresses learned from the PW that terminates in the all the MAC addresses learned from the PW in the VPLS in the context
remote VSI identified by the PE-ID element. on which the MAC Flush message is received.
If a PE-ID element received in the MAC flush message identifies the If a MAC Flush TLV is received with N = 0 in the MAC flush message
local VSI, it SHOULD flush the MAC addresses learned from its local then the receiving PE SHOULD flush the MAC addresses learned from all
spoke PW(s) in the VPLS instance. 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 PE-ID TLV option and a If a PE device receives a MAC flush with the MAC Flush TLV option and
valid MAC address list, it SHOULD ignore the option and deal with MAC a valid MAC address list, it SHOULD ignore the option and deal with
addresses explicitly as per [RFC4762]. 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 MAC Flush TLV receives a MAC
message with this option, it MUST ignore the option and follow the flush message with this option, it MUST ignore the option and follow
processing rules as per [RFC4762]. the processing rules as per [RFC4762]. However if the 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 4.1.4. 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. When the backup PW is activated by MTU-s, it scenario in Figure 1. When the primary spoke PW transition (failure
may send MAC flush message to PE-2 with the FEC TLV and the optional or standby transition) is detected by PE-1, it may send MAC flush
PE-ID TLV. The PE-ID element carries the VSI identifier in PE-1 for messages to PE-2, PE-3 and PE-4 with a MAC Flush TLV and N = 1. Upon
the VPLS. Upon receipt of the MAC flush message, PE-2 identifies the receipt of the MAC flush message, PE-2 identifies the VPLS instance
VPLS instance that requires MAC flush from the FEC element in the FEC that requires the MAC flush from the FEC element in the FEC TLV. On
TLV. From the PE-ID TLV, PE-2 identifies the PW in the VPLS that receiving N=1, PE-2 removes all MAC addresses learned from that PW
terminates in PE-1. PE-2 removes all MAC addresses learned from that over which the message is received. Same action is followed by PE-3
PW. PE-2 relays MAC flush messages with the received PE-ID to all its and PE-4.
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
MAC addresses learned on the PW that terminated in PE1. There may be
redundancy scenerios where a PE device in the full mesh may be
required to initiate optimized MAC Address Withdrawal. Figure 3 shows
a 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 Figure 3 shows another redundant H-VPLS topology to protect against
|| || \ /|| failure of MTU-s device. Provider RSTP may be used as selection
|| Redundancy || \ / || algorithm for active and backup PWs in order to maintain the
|| Provider RSTP || Full-Mesh . || connectivity between MTU devices and PE devices at the edge. It is
|| || / \ || assumed that PE devices can detect the failure of PWs in either
|| || / \|| direction through OAM mechanisms such as VCCV procedures for
MTU-2----------------PE-2===============PE-4 instance.
MTU-1----------------PE-1------------PE-3
| | \ /|
| Redundancy | \ / |
| Provider RSTP | Full-Mesh . |
| | / \ |
| | / \|
MTU-2================PE-2------------PE-4
Backup PW Backup PW
Figure 3: Redundancy with Provider RSTP Figure 3: Redundancy with Provider RSTP
MTU-1, MTU-2, PE-1 and PE-2 participate in provider RSTP. By 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- 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 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, backup) at the MTU-2 end. When the active PW failure is detected by
it activates the PW between MTU-2 and PE-2. When PE-1 detects the RSTP, it activates the PW between MTU-2 and PE-2. When PE-1 detects
failing PW to MTU-1, it may trigger MAC flush into the full mesh the failing PW to MTU-1, it may trigger a MAC flush into the full
with PE-ID TLV that carries its own VSI identifier in the VPLS. Other mesh with a MAC Flush TLV that carries N=1. Other PE devices in the
PE devices in the full mesh that receive the MAC flush message full mesh that receive the MAC flush message identify their
identify their respective PWs terminating on PE-1 and flush all the respective PWs terminating on PE-1 and flush all the MAC addresses
MAC addresses learned from it. learned from it.
By default, MTU-2 should still trigger MAC flush as currently defined By default, MTU-2 should still trigger MAC flush as currently defined
in [RFC4762] after the backup PW is made active by RSTP. Mechanisms 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 to prevent two copies of MAC withdraws to be sent in such scenarios
is out of scope of this document. is out of scope of this document.
[RFC4762] describes multi-domain VPLS service where fully meshed VPLS [RFC4762] describes multi-domain VPLS services where fully meshed
networks (domains) are connected together by a single spoke PW per VPLS networks (domains) are connected together by a single spoke PW
VPLS service between the VPLS "border" PE devices. To provide per VPLS service between the VPLS "border" PE devices. To provide
redundancy against failure of the inter-domain spoke, full mesh of redundancy against failure of the inter-domain spoke, a full mesh of
inter-domain spokes can be setup between border PE devices and inter-domain spokes can be setup between border PE devices and
provider RSTP may be used for selection of the active inter-domain provider RSTP may be used for selection of the active inter-domain
spoke. In case of inter-domain spoke PW failure, PE initiated MAC spoke. In case of an inter-domain spoke PW failure, PE initiated MAC
withdrawal may be used for optimized MAC flushing within individual withdrawal may be used for optimized MAC flushing within individual
domains. 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 4.2. LDP MAC Withdraw Extensions for PBB-VPLS
The use of Address Withdraw message with MAC List TLV is proposed in The use of Address Withdraw messages with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result [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 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 implicitly the activation of an alternate link in a dual-homing use
case). These existing procedures apply individually to B-VPLS and I- case). These existing procedures apply individually to B-VPLS and I-
component domains. component domains.
When it comes to reflecting topology changes in access networks When it comes to reflecting topology changes in access networks
connected to I-component across the B-VPLS domain certain additions connected to I-component across the B-VPLS domain certain additions
should be considered as described below. should be considered as described below.
skipping to change at page 14, line 32 skipping to change at page 14, line 44
There is a need to indicate the PBB PE (BMAC source) that originated 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 the MAC Flush message to selectively flush only the MACs that are
affected. affected.
These goals can be achieved by adding a new MAC Flush Parameters TLV These goals can be achieved by adding a new MAC Flush Parameters TLV
in the LDP Address Withdraw message to indicate the particular in the LDP Address Withdraw message to indicate the particular
domain(s) requiring MAC flush. On the other end, the receiving PEs 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 may use the information from the new TLV to flush only the related
FIB entry/entries in the I-component instance(s). FIB entry/entries in the I-component instance(s).
4.2.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 an 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
for the B-VPLS is required. C flag MUST be set (C=1) when the MAC
Flush for I-VPLS is required.
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.
MBZ flags, the rest of the flags should be set to zero on
transmission and ignored on reception.
The following sub-TLVs MUST be included in the MAC Flush Parameters The following sub-TLVs MUST be included in the MAC Flush Parameters
TLV if the C-flag is set to 1: TLV if the C-flag is set to 1:
- PBB BMAC List sub-TLV: - PBB BMAC List sub-TLV:
Type: 0x01 Type: 0x01
Length: value length in octets. At least one BMAC address must be Length: value length in octets. At least one BMAC address must be
present in the list. present in the list.
Value: one or a list of 48 bits BMAC addresses. These are the source Value: one or a list of 48 bits BMAC addresses. These are the source
BMAC addresses associated with the B-VPLS instance that originated BMAC addresses associated with the B-VPLS instance that originated
the MAC Withdraw message. It will be used to identify the CMAC(s) the MAC Withdraw message. It will be used to identify the CMAC(s)
mapped to the BMAC(s) listed in the sub-TLV. mapped to the BMAC(s) listed in the sub-TLV.
- PBB ISID List sub-TLV: - PBB ISID List sub-TLV:
skipping to change at page 16, line 23 skipping to change at page 15, line 28
Type: 0x02, Type: 0x02,
Length: value length in octets. Zero indicates an empty ISID list. An 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 empty ISID list means that the flush applies to all the ISIDs mapped
to the B-VPLS indicated by the FEC TLV. to the B-VPLS indicated by the FEC TLV.
Value: one or a list of 24 bits ISIDs that represent the I-component Value: one or a list of 24 bits ISIDs that represent the I-component
FIB(s) where the MAC Flush needs to take place. FIB(s) where the MAC Flush needs to take place.
4.2.2. MAC Flush Parameters TLV Processing Rules 4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS
The following steps describe the details of the processing for the The following steps describe the details of the processing for the
related LDP Address Withdraw message: related LDP Address Withdraw message:
. The LDP MAC Withdraw Message, including the MAC Flush Parameters . The LDP MAC Withdraw Message, including the MAC Flush Parameters
TLV is initiated by the PBB PE(s) experiencing a Topology Change TLV is initiated by the PBB PE(s) experiencing a Topology Change
event in one or multiple customer I-component(s). event in one or multiple customer I-component(s).
o The flags are set accordingly to indicate the type of MAC o The flags are set accordingly to indicate the type of MAC
Flush required for this event: N=0 (Flush-all-but-mine), Flush required for this event: N=0 (Flush-all-but-mine) or
C=1 (Flush only CMAC FIBs). N = 1 (Flush-all-from-me), C=1 (Flush only CMAC FIBs).
o The PBB Sub-TLVs (BMAC and ISID Lists) are included o The PBB Sub-TLVs (BMAC and ISID Lists) are included
according to the context of topology change. according to the context of topology change.
. On reception of the LDP Address Withdrawal message, the B-VPLS . On reception of the LDP Address Withdrawal message, the B-VPLS
instances corresponding to the FEC TLV in the message must instances corresponding to the FEC TLV in the message must
interpret the content of MAC Flush Parameters TLV. If the C-bit is 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 set to 1 then Backbone Core Bridges (BCB) in the PBB-VPLS SHOULD
NOT flush their BMAC FIBs. The B-VPLS control plane SHOULD NOT flush their BMAC FIBs. The B-VPLS control plane SHOULD
propagate the MAC Flush following the split-horizon grouping and propagate the MAC Flush following the split-horizon grouping and
the established B-VPLS topology. the established B-VPLS topology.
. The usage and processing rules of MAC Flush Parameters TLV in the . The usage and processing rules of MAC Flush Parameters TLV in the
context of Backbone Edge Bridges (BEB) is as follows: context of Backbone Edge Bridges (BEB) is as follows:
.
o The PBB ISID List is used to determine the particular ISID 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 FIBs (I-VPLS) that need to be flushed. If the ISID List is
empty then all the ISID FIBs associated with the receiving empty then all the ISID FIBs associated with the receiving
B-VPLS SHOULD be flushed. B-VPLS SHOULD be flushed.
o The PBB BMAC List is used to identify from the ISID FIBs o The PBB BMAC List is used to identify from the ISID FIBs in
in the previous step to selectively flush BMAC to CMAC the previous step whether to selectively flush BMAC to CMAC
associations depending on the N flag specified below. associations depending on the N flag specified below.
. Next, depending on the N flag value the following actions apply: . Next, depending on the N flag value the following actions apply:
o N=0, all the CMACs in the selected ISID FIBs SHOULD be o N=0, all the CMACs in the selected ISID FIBs SHOULD be
flushed with the exception of the resulted CMAC list from flushed with the exception of the identified CMAC list from
the BMAC List mentioned in the message. ("Flush all but the the BMAC List mentioned in the message. ("Flush all but the
CMACs associated with the BMAC(s) in the BMAC List Sub-TLV CMACs associated with the BMAC(s) in the BMAC List Sub-TLV
from the FIBs associated with the ISID list"). from the FIBs associated with the ISID list").
o N=1, the resulted CMAC list SHOULD be flushed ("Flush all o N=1, the identified CMAC list SHOULD be flushed ("Flush all
the CMACs associated with the BMAC(s) in the BMAC List Sub- the CMACs associated with the BMAC(s) in the BMAC List Sub-
TLV from the FIBs associated with the ISID list"). TLV from the FIBs associated with the ISID list").
4.2.3 Applicability of MAC Flush Parameters TLV 4.2.3 Applicability of MAC Flush Parameters TLV
If MAC Flush Parameters TLV is received by a BEB in a PBB-VPLS If a MAC Flush Parameters TLV is received by a BEB in a PBB-
that does not understand the TLV then it may result in undesirable VPLS that does not understand the TLV then it may result in
MAC flushing action. It is RECOMMENDED that all PE devices undesirable MAC flushing action. It is RECOMMENDED that all PE
participating in PBB-VPLS support MAC Flush Parameters TLV. devices participating in PBB-VPLS support MAC Flush Parameters TLV.
The MAC Flush Parameters TLV is also applicable to regular VPLS The MAC Flush Parameters TLV is also applicable to regular VPLS
context as well. To achieve negative MAC Flush (flush-all-from-me) in contexts. To achieve negative MAC Flush (flush-all-from-me) in a
regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded 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 with C=0 and N = 1 without the inclusion of any Sub-TLVs. Negative
flush is highly desirable in scenarios when VPLS access redundancy is MAC flush is highly desirable in scenarios when VPLS access
provided by Ethernet Ring Protection as specified in ITU-T G.8032 redundancy is provided by Ethernet Ring Protection as specified in
specification etc. [G.8032v2] specification etc.
5. Security Considerations 5. Security Considerations
Control plane aspects: Control plane aspects:
- LDP security (authentication) methods as described in [RFC5036] is - LDP security (authentication) methods as described in [RFC5036] is
applicable here. Further this document implements security applicable here. Further this document implements security
considerations as in [RFC4447] and [RFC4762]. considerations as in [RFC4447] and [RFC4762].
Data plane aspects: Data plane aspects:
- This specification does not have any impact on the VPLS forwarding - This specification does not have any impact on the VPLS forwarding
plane. plane.
6. IANA Considerations 6. IANA Considerations
The Type field in PE-ID TLV is defined as 0x405 and is subject to
IANA approval.
The Type field in MAC Flush Parameters TLV is defined as 0x406 and is The Type field in MAC Flush Parameters TLV is defined as 0x406 and is
subject to IANA approval. subject to IANA approval.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank the following people who have The authors would like to thank the following people who have
provided valuable comments and feedback on the topics discussed in provided valuable comments and feedback on the topics discussed in
this document: Marc Lasserre, Dimitri Papadimitriou, Jorge Rabadan, this document: Marc Lasserre, Ian Cowburn, Dimitri Papadimitriou,
Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Jorge Rabadan, Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi,
Henderickx, Jorge Rabadan and Maarten Vissers. Wim Henderickx, Jorge Rabadan and Maarten Vissers.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007. Signaling", RFC 4762, January 2007.
[RFC5036] Andersson, L., et al. "LDP Specification", RFC5036, October [RFC5036] Andersson, L., et al. "LDP Specification", RFC5036, October
skipping to change at page 19, line 10 skipping to change at page 18, line 10
model-00.txt, May 2009 (work in progress) model-00.txt, May 2009 (work in progress)
[RFC4664] Andersson, L., et al. "Framework for Layer 2 Virtual [RFC4664] Andersson, L., et al. "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[802.1w] "IEEE Standard for Local and metropolitan area networks. [802.1w] "IEEE Standard for Local and metropolitan area networks.
Common specifications Part 3: Media Access Control (MAC) Common specifications Part 3: Media Access Control (MAC)
Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std
802.1w-2001. 802.1w-2001.
[G.8032v2] ITU-T G.8032v2 specification
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: pranjal.dutta@alcatel-lucent.com Email: pranjal.dutta@alcatel-lucent.com
Florin Balus Florin Balus
 End of changes. 89 change blocks. 
385 lines changed or deleted 321 lines changed or added

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