draft-ietf-l2vpn-vpls-ldp-mac-opt-02.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-03.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: October 2010 Olen Stokes Expires: January 21, 2011 Olen Stokes
Extreme Networks Extreme Networks
Geraldine Calvignac Geraldine Calvignac
France Telecom France Telecom
July 9, 2010 October 25, 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-02.txt draft-ietf-l2vpn-vpls-ldp-mac-opt-03.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 January 9, 2009. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 MAC convergence on topology change. The procedure also removes MAC
addresses in the VPLS that do not require relearning due to such addresses in the VPLS that do not require relearning due to such
topology change. topology change.
This document defines an enhancement to the MAC Address Withdrawal This document defines an enhancement to the MAC Address Withdrawal
procedure with empty MAC List [RFC4762], which enables a Provider procedure with empty MAC List [RFC4762], which enables a Provider
Edge(PE) device to remove only the MAC addresses that need to be Edge(PE) device to remove only the MAC addresses that need to be
relearned. relearned.
Additional extensions are specified to provide the same functionality Additional extensions to [RFC4762] MAC Withdrawal procedures are
for the PBB-VPLS combination specified in [PBB-VPLS Model]. specified to provide optimized MAC flushing for the PBB-VPLS
specified in [PBB-VPLS Model].
Table of Contents Table of Contents
1. Introduction...................................................3 1.1. Conventions used in this document.........................3
2. Problem Description............................................5 2. Introduction...................................................3
2.1. MAC Flush in regular H-VPLS...............................5 3. Problem Description............................................5
2.2. Blackholing issue in PBB-VPLS.............................6 3.1. MAC Flush in regular H-VPLS...............................5
3. Solution description...........................................8 3.2. Black holing issue in PBB-VPLS............................7
3.1. MAC Flush Optimization for regular H-VPLS.................8 4. Solution description...........................................8
3.1.1. PE-ID TLV Format.....................................8 4.1. MAC Flush Optimization for regular H-VPLS.................8
3.1.2. Application of PE-ID TLV in Optimized MAC Flush.....11 4.1.1. PE-ID TLV Format.....................................8
3.1.3. PE-ID TLV Processing Rules..........................11 4.1.2. Application of PE-ID TLV in Optimized MAC Flush.....11
3.1.4. Optimized MAC Flush Procedures......................12 4.1.3. PE-ID TLV Processing Rules..........................11
3.2. LDP MAC Withdraw Extensions for PBB-VPLS.................13 4.1.4. Optimized MAC Flush Procedures......................12
3.2.1. MAC Flush Parameters TLV format.....................14 4.2. LDP MAC Withdraw Extensions for PBB-VPLS.................14
3.2.2. MAC Flush Parameters TLV Processing Rules...........16 4.2.1. MAC Flush Parameters TLV format.....................14
4. Security Considerations.......................................17 4.2.2. MAC Flush Parameters TLV Processing Rules...........16
5. IANA Considerations...........................................17 5. Security Considerations.......................................17
6. Acknowledgments...............................................17 6. IANA Considerations...........................................18
7. References....................................................17 7. Acknowledgments...............................................18
7.1. Normative References.....................................17 8. References....................................................18
7.2. Informative References...................................18 8.1. Normative References.....................................18
Author's Addresses...............................................18 8.2. Informative References...................................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 35 skipping to change at page 3, line 37
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 (H- additional non-meshed spoke nodes to provide a Hierarchical VPLS (H-
VPLS) service [RFC4762]. VPLS) service [RFC4762].
[PBB-VPLS Model] describes how PBB can be integrated with VPLS to [PBB-VPLS Model] describes how Provider Backbone Bridging (PBB) can
allow for useful PBB capabilities while continuing to avoid the use be integrated with VPLS to allow for useful PBB capabilities while
of MSTP in the backbone. The combined solution referred as PBB-VPLS continuing to avoid the use of MSTP in the backbone. The combined
results in better scalability in terms of number of service solution referred to as PBB-VPLS results in better scalability in
instances, PWs and C-MACs that need to be handled in the VPLS PEs. terms of number of service instances, PWs and C-MACs 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 topology
change in resilient H-VPLS topologies. change in resilient H-VPLS topologies.
An example of usage of the MAC Flush mechanism is the dual-homed H- An example of usage of the MAC Flush mechanism is the dual-homed
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 primary spoke PW and backup spoke PW respectively. Such
redundancy is designed to protect against the failure of primary redundancy is designed to protect against the failure of primary
spoke PW or primary PE device. When the MTU-s switches over to the 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 backup PW, it is required to flush the MAC addresses learned in the
corresponding VSI in peer PE devices participating in full mesh, to corresponding VSI in peer PE devices participating in full mesh, to
avoid black holing of frames to those addresses. Note that forced avoid black holing of frames to those addresses. Note that forced
switchover to backup PW can be also performed at MTU-s switchover to backup PW can be also performed at MTU-s
administratively due to maintenance activities on the primary spoke administratively due to maintenance activities on the primary spoke
PW. When the backup PW is made active by the MTU-s, it triggers LDP 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. Address Withdraw Message with a list of MAC addresses to be flushed.
The 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 a MAC List TLV contains a large number of MAC convergence time and scalability when a MAC List TLV contains a large
addresses, many implementations use a LDP Address Withdraw Message number of MAC addresses, many implementations use a LDP Address
with an empty MAC List. Throughout this document the term MAC Flush Withdraw Message with an empty MAC List. Throughout this document the
Message is used to specify LDP Address Withdraw Message with empty term MAC Flush Message is used to specify LDP Address Withdraw
MAC List described in [RFC4762] unless specified otherwise. Message with empty MAC List described in [RFC4762] unless specified
otherwise.
As per the processing rules in [RFC4762] a PE device on receiving a As per the MAC Address Withdrawal processing rules in [RFC4762] a PE
MAC flush message removes all MAC addresses associated with the device on receiving a MAC flush message removes all MAC addresses
specified VPLS instance (as indicated in the FEC TLV) except the MAC associated with the specified VPLS instance (as indicated in the FEC
addresses learned over the newly activated PW. The PE device further TLV) except the MAC addresses learned over the newly activated PW.
triggers a MAC flush message to each remote PE device connected to it The PE device further triggers a MAC flush message to each remote PE
in the VPLS full mesh. 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 only the
set of MAC addresses that require relearning when topology changes in set of MAC addresses that require relearning when topology changes in
H-VPLS. The solution proposed in this document is generic and is H-VPLS. The solution proposed in this document is generic and is
applicable to MS-PWs in H-VPLS. 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 [PBB-VPLS Model] describes how PBB can be integrated with VPLS to
allow for useful PBB capabilities while continuing to avoid the use allow for useful PBB capabilities while continuing to avoid the use
of MSTP in the backbone. The combined solution referred as PBB-VPLS of 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 C-MACs that need to be handled in the VPLS PEs.
This document describes also extensions to LDP MAC Flush procedures This document describes also extensions to LDP MAC Flush procedures
described in [RFC4762] required to add desirable capabilities to PBB- described in [RFC4762] required to build desirable capabilities to
VPLS solution. PBB-VPLS solution.
Section 2 covers the problem space. Section 3 describes the solution Section 3 covers the problem space. Section 4 describes the solution
and 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 in 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
skipping to change at page 6, line 38 skipping to change at page 7, line 5
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. For
example, at PE-3 all of the MAC addresses learned from the PWs 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. As 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 of 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 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.
3.2. Blackholing 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 PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as
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 I-component control plane throughout
the MPLS core. This is raising an additional challenge related to the MPLS core. This is raising an additional challenge related to
blackhole avoidance in the I-component domain as described in this 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- 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 homed to two I-component instances located on two PBB-VPLS PEs (PE1
and PE2). and PE2).
IP/MPLS Core IP/MPLS Core
+--------------+ +--------------+
|PE2 | |PE2 |
+----+ | +----+ |
|PBB | +-+ | |PBB | +-+ |
_ |VPLS|---|P| | _ |VPLS|---|P| |
S/+----+ /+-+\ |PE3 S/+----+ /+-+\ |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 Blackholing 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 Standby/Blocked status. In the
network diagram CMAC X is one of the MAC addresses located behind CE 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 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 instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2
with BMAC B2. with BMAC B2.
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 of BMAC B1, the
remote PEs participating in the IVPLS (for example, PE3) will learn remote PEs participating in the IVPLS (for example, PE3) will learn
skipping to change at page 11, line 39 skipping to change at page 12, line 5
existing TLVs in MAC Flush message in [RFC4762]. existing TLVs in MAC Flush message in [RFC4762].
4.1.3. PE-ID TLV Processing Rules 4.1.3. 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 PW, 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 active 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 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 towards the core when it detects a spoke PW
failure. In such a case the PE-ID TLV in MAC flush message MAY failure. In such a case the PE-ID TLV in MAC flush message MAY
identify its own VSI. Irrespective of whether it is the MTU-s or PE identify its own VSI. Irrespective of whether it is the MTU-s or PE
device that initiates the MAC flush, a PE device receiving the PE-ID device that initiates the MAC flush, a PE device receiving the PE-ID
TLV SHOULD follow the same processing rules as described in this TLV SHOULD follow the same processing rules as described in this
section. section.
Note that if MS-PW is used in VPLS then a MAC flush message is 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 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 propagate MAC flush messages without any action. In this section, a
PE device signifies only T-PE in MS-PW case unless specified PE device signifies only T-PE in MS-PW case unless specified
skipping to change at page 14, line 10 skipping to change at page 14, line 23
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.
MAC Switching in PBB is based on the mapping of Customer MACs (CMACs) 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- to Backbone MAC(s) (BMACs). A topology change in the access (I-
domain) should just invoke the flushing of CMAC entries in PBB PEs' domain) should just invoke the flushing of CMAC entries in PBB PEs'
FIB(s) associated with the I-component(s) impacted by the failure. 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 There is a need to indicate the PBB PE (BMAC source) that originated
the MAC Flush message. 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 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. At 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 4.2.1. MAC Flush Parameters TLV format
A suggested structure for MAC Flush Parameters TLV is depicted below: The MAC Flush Parameters TLV is described as below:
0 1 2 3 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 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 | |1|1| MAC Flush Params TLV(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sub-TLV Type | Sub-TLV Length | | Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Variable Length Value | | 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 UF bits are set to forward unknown so that potential intermediate The TLV value field contains an one byte Flag field used as described
VPLS PEs unaware of the new TLV can just propagate it transparently. below. Further the TLV value may carry one or more sub-TLVs. Any sub-
The MAC Flush Parameters TLV type value is to be assigned by IANA. TLV definition to the above TLV MUST address the actions in
The Length field is used to define the length of the TLV including combination with other existing sub-TLVs.
the type and the length itself. The TLV value field contains an one
byte Flag field used as described below. A number of sub-TLVs may be
also defined inside the TLV value field. 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: The detailed format for the Flags bit vector is described below:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|C|N| MBZ | (MBZ = MUST Be Zero) |C|N| MBZ | (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
1 Byte Flag field is mandatory. The following flags are defined: 1 Byte Flag field is mandatory. The following flags are defined :
C flag, used to indicate whether the MAC Flush is required in the C flag, used to indicate the context of the PBB-VPLS component in
FIB associated with the VPLS context in which LDP MAC Flush was which MAC flush is required. For PBB-VPLS there are two contexts of
received. For PBB-VPLS this is called Backbone VPLS. C flag MUST be MAC flushing - The Backbone VPLS (B-component VPLS) and Customer
ZERO (C=0) when a MAC Flush for the Backbone VPLS (B-component VPLS (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush
VPLS) is required. C flag MUST be set (C=1) when the MAC Flush for for the B-VPLS is required. C flag MUST be set (C=1) when the MAC
Customer VPLS (I-component VPLS) is required. Flush for I-VPLS is required.
N flag, used to indicate whether a positive (N=0, Flush-all-but- 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. 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 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 LDP session on which the LDP MAC Withdraw was received or with
the BMAC(s) listed in the BMAC Sub-TLV. the BMAC(s) listed in the BMAC Sub-TLV.
MBZ flags, the rest of the flags should be set to zero on MBZ flags, the rest of the flags should be set to zero on
transmission and ignored on reception. 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: 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 19 skipping to change at page 16, line 37
. 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),
C=1 (Flush only CMAC FIBs). 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.
. On reception of the LDP message, the B-VPLS instances related to . On reception of the LDP Address Withdrawal message, the B-VPLS
the FEC TLV from the LDP Address Withdraw message must interpret instances corresponding to the FEC TLV in the message must
the content of MAC Flush Parameters TLV. If the C-bit is set the interpret the content of MAC Flush Parameters TLV. If the C-bit is
BCBs should not flush their BMAC FIBs. The B-VPLS control plane set to 1 then Backbone Core Bridges (BCB) in the PBB-VPLS SHOULD
may propagate the MAC Flush indication following the split-horizon NOT flush their BMAC FIBs. The B-VPLS control plane SHOULD
grouping and the established BVPLS topology. propagate the MAC Flush following the split-horizon grouping and
the established B-VPLS topology.
. The receiving BEBs use the sub-TLVs from the MAC Flush Parameters . The usage and processing rules of MAC Flush Parameters TLV in the
TLV 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 that need to be flushed. If the ISID List is empty all FIBs (I-VPLS) that need to be flushed. If the ISID List is
the ISID FIBs associated with the receiving B-VPLS are empty then all the ISID FIBs associated with the receiving
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
selected in the previous step just the entries that map in the previous step to selectively flush BMAC to CMAC
CMACs to the BMACs that are not listed in the sub-TLV. 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 flushed with the exception of the resulted CMAC list from
("Flush all but the CMACs associated with the BMAC(s) in the BMAC List mentioned in the message. ("Flush all but the
the BMAC List Sub-TLV from the FIBs associated with the CMACs associated with the BMAC(s) in the BMAC List Sub-TLV
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 resulted 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
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 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 The Type field in PE-ID TLV is defined as 0x405 and is subject to
IANA approval. IANA approval.
IANA needs to assign MAC Flush Parameters TLV type values. The Type field in MAC Flush Parameters TLV is defined as 0x406 and is
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, Dimitri Papadimitriou, Jorge Rabadan,
Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim
Henderickx, Jorge Rabadan and Maarten Vissers. Henderickx, Jorge Rabadan and Maarten Vissers.
8. References 8. References
 End of changes. 36 change blocks. 
95 lines changed or deleted 121 lines changed or added

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