draft-ietf-l2vpn-vpls-ldp-mac-opt-09.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-10.txt 
Network Working Group P. Dutta Network Working Group P. Dutta
Internet-Draft F. Balus Internet-Draft F. Balus
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: May 31, 2014 O. Stokes Expires: July 25, 2014 O. Stokes
Extreme Networks Extreme Networks
G. Calvinac G. Calvinac
France Telecom France Telecom
November 27, 2013 January 21, 2014
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-09 draft-ietf-l2vpn-vpls-ldp-mac-opt-10
Abstract Abstract
RFC4762 describes a mechanism to remove or unlearn MAC addresses that RFC4762 describes a mechanism to remove or unlearn MAC addresses that
have been dynamically learned in a VPLS Instance for faster have been dynamically learned in a Virtual Private LAN Service (VPLS)
convergence on topology change. The procedure also removes MAC Instance for faster convergence on topology change. The procedure
addresses in the VPLS that do not require relearning due to such also removes MAC addresses in the VPLS that do not require relearning
topology change. This document defines an enhancement to the MAC due to such topology change. This document defines an enhancement to
Address Withdrawal procedure with empty MAC List from RFC4762, which the MAC Address Withdrawal procedure with empty MAC List from
enables a Provider Edge(PE) device to remove only the MAC addresses RFC4762, which enables a Provider Edge(PE) device to remove only the
that need to be relearned. Additional extensions to RFC4762 MAC MAC addresses that need to be relearned. Additional extensions to
Withdrawal procedures are specified to provide optimized MAC flushing RFC4762 MAC Withdrawal procedures are specified to provide optimized
for the PBB-VPLS specified in working group RFC7041. MAC flushing for the PBB-VPLS specified in RFC7041.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 31, 2014. This Internet-Draft will expire on May 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. MAC Flush on activation of backup spoke PW . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. PE-rs initiated MAC Flush . . . . . . . . . . . . . . 6 3.1. MAC Flush on activation of backup spoke PW . . . . . . . . 6
2.1.2. MTU-s initiatied MAC flush . . . . . . . . . . . . . . 6 3.1.1. PE-rs initiated MAC Flush . . . . . . . . . . . . . . 7
2.2. MAC Flush on failure . . . . . . . . . . . . . . . . . . . 7 3.1.2. MTU-s initiatied MAC flush . . . . . . . . . . . . . . 7
2.3. MAC Flush in PBB-VPLS . . . . . . . . . . . . . . . . . . 7 3.2. MAC Flush on failure . . . . . . . . . . . . . . . . . . . 8
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 8 3.3. MAC Flush in PBB-VPLS . . . . . . . . . . . . . . . . . . 8
3.1. MAC Flush Optimization in VPLS Resiliency . . . . . . . . 8 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. MAC Flush Optimization for regular H-VPLS . . . . . . 8 4.1. MAC Flush Optimization in VPLS Resiliency . . . . . . . . 9
3.1.2. MAC Flush Optimization for native Ethernet access . . 10 4.1.1. MAC Flush Optimization for regular H-VPLS . . . . . . 9
3.2. Black holing issue in PBB-VPLS . . . . . . . . . . . . . . 11 4.1.2. MAC Flush Optimization for native Ethernet access . . 11
4. Solution Description . . . . . . . . . . . . . . . . . . . . . 12 4.2. Black holing issue in PBB-VPLS . . . . . . . . . . . . . . 12
4.1. MAC Flush Optimization for VPLS Resiliency . . . . . . . . 12 5. Solution Description . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. MAC Flush Parameters TLV . . . . . . . . . . . . . . . 13 5.1. MAC Flush Optimization for VPLS Resiliency . . . . . . . . 13
4.1.2. Application of MAC Flush TLV in Optimized MAC Flush . 14 5.1.1. MAC Flush Parameters TLV . . . . . . . . . . . . . . . 14
4.1.3. MAC Flush TLV Processing Rules for Regular VPLS . . . 14 5.1.2. Application of MAC Flush TLV in Optimized MAC Flush . 15
4.1.4. Optimized MAC Flush Procedures . . . . . . . . . . . . 15 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS . . . 15
4.2. LDP MAC Flush Extensions for PBB-VPLS . . . . . . . . . . 16 5.1.4. Optimized MAC Flush Procedures . . . . . . . . . . . . 16
4.2.1. MAC Flush TLV Processing Rules for PBB-VPLS . . . . . 17 5.2. LDP MAC Flush Extensions for PBB-VPLS . . . . . . . . . . 17
4.2.2. Applicability of MAC Flush Parameters TLV . . . . . . 19 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS . . . . . 18
5. Operational Considerations . . . . . . . . . . . . . . . . . . 19 5.2.2. Applicability of MAC Flush Parameters TLV . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Operational Considerations . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Terminology 1. Terminology
This document uses the terminology defined in [RFC7041], [RFC5036], This document uses the terminology defined in [RFC7041], [RFC5036],
[RFC4447] and [RFC4762]. [RFC4447] and [RFC4762].
Throughout this document VPLS means the emulated bridged LAN service Throughout this document Virtual Private LAN Service (VPLS) means the
offered to a customer. H-VPLS means the hierarchical connectivity or emulated bridged LAN service offered to a customer. H-VPLS means the
layout of MTU-s and PE-rs devices offering the VPLS [RFC4762]. hierarchical connectivity or layout of MTU-s and PE-rs devices
offering the VPLS [RFC4762].
The terms "Spoke Node" and "MTU-s" in H-VPLS are used The terms "Spoke Node" and "MTU-s" in H-VPLS are used
interchangeably. interchangeably.
"Spoke PW" means the PW (Pseudowire) that provides connectivity "Spoke PW" means the PW (Pseudowire) that provides connectivity
between MTU-s and PE-rs nodes. between MTU-s and PE-rs nodes.
"Mesh PW" means the PW that provides connectivity between PE-rs nodes "Mesh PW" means the PW that provides connectivity between PE-rs nodes
in a VPLS full mesh core. in a VPLS full mesh core.
skipping to change at page 5, line 17 skipping to change at page 6, line 5
"How a spoke is designated primary or secondary is outside the scope "How a spoke is designated primary or secondary is outside the scope
of this document. For example, a spanning tree instance running of this document. For example, a spanning tree instance running
between only the MTU-s and the two PE-rs nodes is one possible between only the MTU-s and the two PE-rs nodes is one possible
method. Another method could be configuration". method. Another method could be configuration".
This document intends to clarify several H-VPLS dual-homing models This document intends to clarify several H-VPLS dual-homing models
that are deployed in practice and various use cases of LDP based MAC that are deployed in practice and various use cases of LDP based MAC
flush in these models. flush in these models.
3. Overview
When the MTU-s switches over to the backup PW, the requirement is to When the MTU-s switches over to the backup PW, the requirement is to
flush the MAC addresses learned in the corresponding VSI in peer PE flush the MAC addresses learned in the corresponding Virtual Switch
devices participating in the full mesh, to avoid black holing of Instance (VSI) in peer PE devices participating in the full mesh, to
frames to those addresses. This is accomplished by sending an LDP avoid black holing of frames to those addresses. This is
Address Withdraw Message from the PE that is no longer connected to accomplished by sending an LDP Address Withdraw Message from the PE
the MTU-s with the primary PW, with the list of MAC addresses to be that is no longer connected to the MTU-s with the primary PW, with
removed to all other PEs over the corresponding LDP sessions the list of MAC addresses to be removed to all other PEs over the
[RFC4762]. corresponding LDP sessions [RFC4762].
In order to minimize the impact on LDP convergence time and In order to minimize the impact on LDP convergence time and
scalability when a MAC List TLV contains a large number of MAC scalability when a MAC List TLV contains a large number of MAC
addresses, many implementations use a LDP Address Withdraw Message addresses, many implementations use a LDP Address Withdraw Message
with an empty MAC List. Throughout this document the term "MAC Flush with an empty MAC List. Throughout this document the term "MAC Flush
Message" is used to specify LDP Address Withdraw Message with an Message" is used to specify LDP Address Withdraw Message with an
empty MAC List described in [RFC4762] unless specified otherwise. The empty MAC List described in [RFC4762] unless specified otherwise. The
solutions described in this document are applicable only to LDP solutions described in this document are applicable only to LDP
Address Withdraw Message with empty MAC List. Address Withdraw Message with empty MAC List.
skipping to change at page 5, line 46 skipping to change at page 6, line 36
on the PE-rs nodes. However when the VPLS topology changes, the on the PE-rs nodes. However when the VPLS topology changes, the
PE-rs must relearn using MAC Addresses withdrawal or flush. As per PE-rs must relearn using MAC Addresses withdrawal or flush. As per
the MAC Address Withdrawal processing rules in [RFC4762] a PE device the MAC Address Withdrawal processing rules in [RFC4762] a PE device
on receiving a MAC Flush Message removes all MAC addresses associated on receiving a MAC Flush Message removes all MAC addresses associated
with the specified VPLS instance (as indicated in the FEC TLV) except with the specified VPLS instance (as indicated in the FEC TLV) except
the MAC addresses learned over the PW associated with this signaling the MAC addresses learned over the PW associated with this signaling
session over which the message was received. Throughout this session over which the message was received. Throughout this
document we use the terminology "Positive" MAC Flush or "Flush-all- document we use the terminology "Positive" MAC Flush or "Flush-all-
but-mine" for this type of MAC Flush Message and its actions. but-mine" for this type of MAC Flush Message and its actions.
2.1. MAC Flush on activation of backup spoke PW 3.1. MAC Flush on activation of backup spoke PW
This section describes scenarios where MAC Flush withdrawal is This section describes scenarios where MAC Flush withdrawal is
initiated on activation of backup PW in H-VPLS. initiated on activation of backup PW in H-VPLS.
2.1.1. PE-rs initiated MAC Flush 3.1.1. PE-rs initiated MAC Flush
[RFC4762] specifies that on failure of the primary PW, it is the [RFC4762] specifies that on failure of the primary PW, it is the
PE3-rs (Figure 1) that initiates MAC flush towards the core. However PE3-rs (Figure 1) that initiates MAC flush towards the core. However
note that PE3-rs can initiate MAC Flush only when PE3-rs is dual note that PE3-rs can initiate MAC Flush only when PE3-rs is dual
homing "aware" - that is, there is some redundancy management homing "aware" - that is, there is some redundancy management
protocol running between MTU-s and its host PE-rs devices. The scope protocol running between MTU-s and its host PE-rs devices. The scope
of this document is not specific to any dual homing protocols. One of this document is not specific to any dual homing protocols. One
example could be BGP based multi-homing in LDP based VPLS that uses example could be BGP based multi-homing in LDP based VPLS that uses
the procedures defined in [I-D.ietf-l2vpn-vpls-multihoming]. In this the procedures defined in [I-D.ietf-l2vpn-vpls-multihoming]. In this
method of dual-homing, PE3-rs would neither forward any traffic to method of dual-homing, PE3-rs would neither forward any traffic to
MTU-s neither would receive any traffic from MTU-s while PE1-rs is MTU-s nor would it receive any traffic from MTU-s while PE1-rs is
acting a primary (or designated forwarder). acting as a primary (or designated forwarder).
2.1.2. MTU-s initiatied MAC flush 3.1.2. MTU-s initiatied MAC flush
When dual homing is achieved by manual configuration in MTU-s, the When dual homing is achieved by manual configuration in MTU-s, the
hosting PE-rs devices are dual homing "agnostic" and PE3-rs can not hosting PE-rs devices are dual homing "agnostic" and PE3-rs can not
initiate MAC Flush message. PE3-rs can send or receive traffic over initiate MAC Flush message. PE3-rs can send or receive traffic over
the backup PW since the dual-homing control is with MTU-s only. When the backup PW since the dual-homing control is with MTU-s only. When
the backup PW is made active by the MTU-s, the MTU-s triggers MAC the backup PW is made active by the MTU-s, the MTU-s triggers MAC
Flush Message. The message is sent over the LDP session associated Flush Message. The message is sent over the LDP session associated
with the newly activated PW. On receiving the MAC Flush Message from with the newly activated PW. On receiving the MAC Flush Message from
MTU-s, PE3-rs (PE-rs device with now-active PW) would flush all the MTU-s, PE3-rs (PE-rs device with now-active PW) would flush all the
MAC addresses it has learned except the ones learned over the newly MAC addresses it has learned except the ones learned over the newly
activated spoke PW. PE3-rs further initiates a MAC Flush Message to activated spoke PW. PE3-rs further initiates a MAC Flush Message to
all other PE devices in the core. Note that forced switchover to all other PE devices in the core. Note that forced switchover to
backup PW can be also performed at MTU-s administratively due to backup PW can be also performed at MTU-s administratively due to
maintenance activities on the "erstwhile" primary spoke PW. maintenance activities on the former primary spoke PW.
MTU-s initiated method of MAC flushing is modeled after Topology MTU-s initiated method of MAC flushing is modeled after Topology
Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP) Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)
[IEEE.802.1Q-2011]. When a bridge switches from a failed link to the [IEEE.802.1Q-2011]. When a bridge switches from a failed link to the
backup link, the bridge sends out a TCN message over the newly backup link, the bridge sends out a TCN message over the newly
activated link. The upstream bridge upon receiving this message activated link. The upstream bridge upon receiving this message
flushes its entire MAC addresses except the ones received over this flushes its entire MAC addresses except the ones received over this
link and sends the TCN message out of its other ports in that link and sends the TCN message out of its other ports in that
spanning tree instance. The message is further relayed along the spanning tree instance. The message is further relayed along the
spanning tree by the other bridges. spanning tree by the other bridges.
skipping to change at page 7, line 14 skipping to change at page 8, line 14
is not propagated to other mesh PWs. is not propagated to other mesh PWs.
Irrespective of whether a MAC Flush is initiated by a PE-rs or MTU-s, Irrespective of whether a MAC Flush is initiated by a PE-rs or MTU-s,
when a PE-rs device in the full-mesh of H-VPLS receives a MAC flush when a PE-rs device in the full-mesh of H-VPLS receives a MAC flush
message it also flushes MAC addresses which are not affected due to message it also flushes MAC addresses which are not affected due to
topology change, thus leading to unnecessary flooding and relearning. topology change, thus leading to unnecessary flooding and relearning.
This document describes an optional mechanism to optimize the MAC This document describes an optional mechanism to optimize the MAC
flush procedure in [RFC4762] so that it flushes only the set of MAC flush procedure in [RFC4762] so that it flushes only the set of MAC
addresses that require relearning when topology changes in H-VPLS. addresses that require relearning when topology changes in H-VPLS.
2.2. MAC Flush on failure 3.2. MAC Flush on failure
MAC Flush on failure is introduced in this document. In this model, MAC Flush on failure is introduced in this document. In this model,
the MAC Flush is initiated by PE1-rs (Figure 1) on detection of the MAC Flush is initiated by PE1-rs (Figure 1) on detection of
failure of the primary spoke PW and is sent to all participating failure of the primary spoke PW and is sent to all participating
PE-rs devices in the VPLS full-mesh. PE1-rs SHOULD initiate MAC PE-rs devices in the VPLS full-mesh. PE1-rs SHOULD initiate MAC
flush only if PE1-rs is dual homing aware. (If PE1-rs is dual homing flush only if PE1-rs is dual homing aware. (If PE1-rs is dual homing
agnostic, the policy is do not initiate a MAC flush on failure, since agnostic, the policy is do not initiate a MAC flush on failure, since
that could cause unnecessary flushing in the case of single homed that could cause unnecessary flushing in the case of single homed
MTU-s.) The dual-homing protocols for this scenario are outside the MTU-s.) The dual-homing protocols for this scenario are outside the
scope of this document. For example, the case of PE1-rs initiated scope of this document. For example, the case of PE1-rs initiated
MAC flush on failure may arise when the dual-homing segment is native MAC flush on failure may arise when the dual-homing segment is native
ethernet as opposed to spoke PWs. In this case the PE-rs devices ethernet as opposed to spoke PWs. In this case the PE-rs devices
that receives the MAC flush from PE1-rs are required to flush all the that receive the MAC flush from PE1-rs are required to flush all the
MAC addresses learned over the PW connected to PE1-rs. This cannot MAC addresses learned over the PW connected to PE1-rs. This cannot
be achieved with the MAC Address Withdraw Message defined in be achieved with the MAC Address Withdraw Message defined in
[RFC4762]. This document describes extensions to MAC Flush [RFC4762]. This document describes extensions to MAC Flush
procedures defined in [RFC4762] in order to implement MAC Flush on procedures defined in [RFC4762] in order to implement MAC Flush on
Failure. We use the term "negative" MAC flush or "Flush-all-from-me" Failure. We use the term "negative" MAC flush or "Flush-all-from-me"
for this kind of flushing action as opposed to "positive" MAC Flush for this kind of flushing action as opposed to "positive" MAC Flush
action in [RFC4762]. The negative MAC flush typically results is a action in [RFC4762]. The negative MAC flush typically results is a
smaller set of MACs to be flushed. smaller set of MACs to be flushed.
Note that in the case of negative flush the list SHOULD be only the Note that in the case of negative flush the list SHOULD be only the
MACs for the affected MTU-s. If the list is empty then the negative MACs for the affected MTU-s. If the list is empty then the negative
flush will result in flushing and relearning all attached MTU-s for flush will result in flushing and relearning all attached MTU-s's for
the originating PE-rs. the originating PE-rs.
2.3. MAC Flush in PBB-VPLS 3.3. MAC Flush in PBB-VPLS
[RFC7041] describes how PBB can be integrated with VPLS to allow for [RFC7041] describes how PBB can be integrated with VPLS to allow for
useful PBB capabilities while continuing to avoid the use of MSTP in useful PBB capabilities while continuing to avoid the use of MSTP in
the backbone. The combined solution referred to as "PBB-VPLS" the backbone. The combined solution referred to 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 PE-rs instances, PWs and C-MACs that need to be handled in the VPLS PE-rs
devices. This document describes extensions to LDP MAC Flush devices. This document describes extensions to LDP MAC Flush
procedures described in [RFC4762] required to build desirable procedures described in [RFC4762] required to build desirable
capabilities to PBB-VPLS solution. capabilities to PBB-VPLS solution.
The solution proposed in this document is generic and is applicable The solution proposed in this document is generic and is applicable
when MS-PWs are used in interconnecting PE devices in H-VPLS. There when MS-PWs are used in interconnecting PE devices in H-VPLS. There
could be other H-VPLS models not defined in this document where the could be other H-VPLS models not defined in this document where the
solution may be applicable. solution may be applicable.
3. Problem Description 4. Problem Description
This document describes the problems in detail with respective to This document describes the problems in detail with respective to
various MAC flush actions described in section 2. various MAC flush actions described in section 2.
3.1. MAC Flush Optimization in VPLS Resiliency 4.1. MAC Flush Optimization in VPLS Resiliency
This section describes the optimizations required in MAC flush This section describes the optimizations required in MAC flush
procedures when H-VPLS resiliency is provided by primary and backup procedures when H-VPLS resiliency is provided by primary and backup
spoke PWs. spoke PWs.
3.1.1. MAC Flush Optimization for regular H-VPLS 4.1.1. MAC Flush Optimization for regular H-VPLS
Figure 2. describes a dual-homed H-VPLS scenario for a VPLS instance Figure 2. describes a dual-homed H-VPLS scenario for a VPLS instance
where the problem with the existing MAC flush method (section 2) is where the problem with the existing MAC flush method explained in
explained. [RFC4762] section 3.
PE1-rs PE3-rs PE1-rs PE3-rs
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
| -- | | -- | | -- | | -- |
Customer Site 1 | / \ |------------------| / \ |->Z Customer Site 1 | / \ |------------------| / \ |->Z
X->CE-1 /-----| \s / | | \s / | X->CE-1 /-----| \s / | | \s / |
\ primary spoke PW | -- | /------| -- | \ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+ \ / +--------+ / +--------+
\ (MTU-s)/ | \ / | \ (MTU-s)/ | \ / |
+--------+/ | \ / | +--------+/ | \ / |
skipping to change at page 10, line 44 skipping to change at page 11, line 44
only the MAC addresses in set X and Y need to be flushed across the only the MAC addresses in set X and Y need to be flushed across the
core. core.
The same case is applicable when PE1-rs and PE2-rs are dual homing The same case is applicable when PE1-rs and PE2-rs are dual homing
aware and participate in a designated forwarder election. When aware and participate in a designated forwarder election. When
PE2-rs becomes the active device for MTU-s then PE2-rs MAY initiate PE2-rs becomes the active device for MTU-s then PE2-rs MAY initiate
MAC flush towards the core. The receiving action of the MAC Flush in MAC flush towards the core. The receiving action of the MAC Flush in
other PE-rs devices is the same as in MTU-s initiated MAC Flush. This other PE-rs devices is the same as in MTU-s initiated MAC Flush. This
is the [RFC4762] specified behavior. is the [RFC4762] specified behavior.
3.1.2. MAC Flush Optimization for native Ethernet access 4.1.2. MAC Flush Optimization for native Ethernet access
The analysis in section 3.1.1 applies also to the native Ethernet The analysis in section 3.1.1 applies also to the native Ethernet
access into a VPLS. In such a scenario one active and one or more access into a VPLS. In such a scenario one active and one or more
standby endpoints terminate into two or more VPLS or H-VPLS PE-rs standby endpoints terminate into two or more VPLS or H-VPLS PE-rs
devices. Examples of these dual homed access are ITU-T [ITU.G8032] devices. Examples of these dual homed access are ITU-T [ITU.G8032]
access rings or any proprietary multi-chassis LAG emulations. Upon access rings or any proprietary multi-chassis LAG emulations. Upon
failure of the active native Ethernet endpoint on PE1-rs, an failure of the active native Ethernet endpoint on PE1-rs, an
optimized MAC flush is required to be initiated by PE1-rs to ensure optimized MAC flush is required to be initiated by PE1-rs to ensure
that on PE2-rs, PE3-rs and PE4-rs only the MAC addresses learned from that on PE2-rs, PE3-rs and PE4-rs only the MAC addresses learned from
the respective PWs connected to PE1-rs are being flushed. the respective PWs connected to PE1-rs are being flushed.
3.2. Black holing issue in PBB-VPLS 4.2. Black holing issue in PBB-VPLS
In a PBB-VPLS deployment a B-component VPLS (B-VPLS) may be used as In a PBB-VPLS deployment a B-component VPLS (B-VPLS) may be used as
infrastructure to support one or more I-component instances. The infrastructure to support one or more I-component instances. The
B-VPLS control plane (LDP Signaling) and learning of "Backbone" MACs B-VPLS control plane (LDP Signaling) and learning of "Backbone" MACs
(BMACs) replaces I-component control plane and learning of customer (BMACs) replaces I-component control plane and learning of customer
MACs (CMACs) throughout the MPLS core. This raises an additional MACs (CMACs) throughout the MPLS core. This raises an additional
challenge related to black hole avoidance in the I-component domain challenge related to black hole avoidance in the I-component domain
as described in this section. Figure 3 describes the case of a CE as described in this section. Figure 3 describes the case of a CE
device (node A) dual-homed to two I-component instances located on device (node A) dual-homed to two I-component instances located on
two PBB-VPLS PEs (PE1-rs and PE2-rs). two PBB-VPLS PEs (PE1-rs and PE2-rs).
skipping to change at page 11, line 48 skipping to change at page 12, line 48
network diagram CMAC X is one of the MAC addresses located behind 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 B-VPLS CE-A in the customer domain, CMAC Y is behind CE-B and the B-VPLS
instances on PE1-rs are associated with BMAC B1 and PE2-rs with BMAC instances on PE1-rs are associated with BMAC B1 and PE2-rs with BMAC
B2. B2.
As the packets flow from CMAC X to CMAC Y through PE1-rs with BMAC As the packets flow from CMAC X to CMAC Y through PE1-rs with BMAC
B1, the remote PE-rs devices participating in the B-VPLS with the B1, the remote PE-rs devices participating in the B-VPLS with the
same I-SID (for example, PE3-rs) will learn the CMAC X associated same I-SID (for example, PE3-rs) will learn the CMAC X associated
with BMAC B1 on PE1-rs. Under a failure condition of the link with BMAC B1 on PE1-rs. Under a failure condition of the link
between CE-A and PE1-rs and on activation of the link to PE2-rs, the between CE-A and PE1-rs and on activation of the link to PE2-rs, the
remote PE-rs devices (for example, PE3-rs) will black-hole the remote PE-rs devices (for example, PE3-rs) will forward the traffic
traffic destined for customer MAC X to BMAC B1 until the aging timer destined for customer MAC X to BMAC B1 resulting in PE1-rs
expires or a packet flows from X to Y through the PE B2. This may blackholing that traffic until the aging timer expires or a packet
take a long time (default aging timer is 5 minutes) and may affect a flows from X to Y through the PE2-rs, BMAC B2. This may take a long
large number of flows across multiple I-components. time (default aging timer is 5 minutes) and may affect a large number
of flows across multiple I-components.
A possible solution to this issue is to use the existing LDP MAC A possible solution to this issue is to use the existing LDP MAC
Flush as specified in [RFC4762] to flush the BMAC associated with the Flush as specified in [RFC4762] to flush the BMAC associated with the
PE-rs in the B-VPLS domain where the failure occurred. This will PE-rs in the B-VPLS domain where the failure occurred. This will
automatically flush the CMAC to BMAC association in the remote PE-rs automatically flush the CMAC to BMAC association in the remote PE-rs
devices. This solution has the disadvantage of producing a lot of devices. This solution has the disadvantage of producing a lot of
unnecessary MAC flush in the B-VPLS domain as there was no failure or unnecessary MAC flush in the B-VPLS domain as there was no failure or
topology change affecting the Backbone domain. topology change affecting the Backbone domain.
A better solution which propagates the I-component events through the A better solution which propagates the I-component events through the
backbone infrastructure (B-VPLS) is required in order to flush only backbone infrastructure (B-VPLS) is required in order to flush only
the CMAC to BMAC associations in the remote PBB-VPLS capable PE-rs the CMAC to BMAC associations in the remote PBB-VPLS capable PE-rs
devices. Since there are no I-component control plane exchanges devices. Since there are no I-component control plane exchanges
across the PBB backbone, extensions to B-VPLS control plane are across the PBB backbone, extensions to B-VPLS control plane are
required to propagate the I-component MAC Flush events across the required to propagate the I-component MAC Flush events across the
B-VPLS. B-VPLS.
4. Solution Description 5. Solution Description
This section describes the solution for the requirements described in This section describes the solution for the requirements described in
section 3. section 3.
4.1. MAC Flush Optimization for VPLS Resiliency 5.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 2. The optimization is achieved by with reference to Figure 2. The optimization is achieved by
initiating MAC Flush on failure as described in section 2.2. initiating MAC Flush on failure as described in section 2.2.
PE1-rs would initiate MAC Flush towards the core on detection of PE1-rs would initiate MAC Flush towards the core on detection of
failure of primary spoke PW between MTU-s and PE1-rs (or status failure of primary spoke PW between MTU-s and PE1-rs (or status
change from active to standby [RFC6718] ). This method is referred change from active to standby [RFC6718] ). This method is referred
as "MAC Flush on Failure" throughout this document. The MAC Flush to as "MAC Flush on Failure" throughout this document. The MAC Flush
message would indicate to receiving PE-rs devices to flush all MACs message would indicate to receiving PE-rs devices to flush all MACs
learned over the PW in the context of the VPLS for which the MAC learned over the PW in the context of the VPLS for which the MAC
flush message is received. Each PE-rs device in the full mesh that flush message is received. Each PE-rs device in the full mesh that
receives the message identifies the VPLS instance and its respective receives the message identifies the VPLS instance and its respective
PW that terminates in PE1-rs from the FEC TLV received in the message PW that terminates in PE1-rs from the FEC TLV received in the message
and/or LDP session. Thus the PE-rs device flushes only the MAC and/or LDP session. Thus the PE-rs device flushes only the MAC
addresses learned from that PW connected to PE1-rs, minimizing the addresses learned from that PW connected to PE1-rs, minimizing the
required relearning and the flooding throughout the VPLS domain. required relearning and the flooding throughout the VPLS domain.
This section defines a generic MAC Flush Parameters TLV for LDP This section defines a generic MAC Flush Parameters TLV for LDP
[RFC5036]. Through out this document the MAC Flush Parameters TLV is [RFC5036]. Through out this document the MAC Flush Parameters TLV is
referred as MAC Flush TLV. A MAC Flush TLV carries information on referred as MAC Flush TLV. A MAC Flush TLV carries information on
the desired action at the PE-rs device receiving the message and is the desired action at the PE-rs device receiving the message and is
used for optimized MAC flushing in VPLS. The MAC Flush TLV can also used for optimized MAC flushing in VPLS. The MAC Flush TLV can also
be used for [RFC4762] style of MAC Flush as explained in section 2. be used for [RFC4762] style of MAC Flush as explained in section 2.
4.1.1. MAC Flush Parameters TLV 5.1.1. MAC Flush Parameters TLV
The MAC Flush Parameters TLV is described as 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 The U and F bits are set to forward if unknown so that potential
intermediate VPLS PE-rs devices unaware of the new TLV can just intermediate VPLS PE-rs devices unaware of the new TLV can just
propagate it transparently. (In the case of an B-VPLS network that propagate it transparently. In the case of an B-VPLS network that
has PBB-VPLS in the core with no I-components attached this message has PBB-VPLS in the core with no I-components attached this message
can still be useful to edge B-VPLS that do have the I-components with can still be useful to edge B-VPLS that do have the I-components with
the ISIDs and understand the message. ) The MAC Flush Parameters TLV the ISIDs and understand the message. The MAC Flush Parameters TLV
type is to be assigned by IANA. The encoding of the TLV follows the type is to be assigned by IANA. The encoding of the TLV follows the
standard LDP TLV encoding in [RFC5036] standard LDP TLV encoding in [RFC5036]
The TLV value field contains a one byte Flag field used as described The TLV value field contains a one byte Flag field used as described
below. Further the TLV value MAY carry one or more sub-TLVs. Any 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 sub-TLV definition to the above TLV MUST address the actions in
combination with other existing sub-TLVs. 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:
skipping to change at page 14, line 21 skipping to change at page 15, line 22
Detailed usage in the context of PBB-VPLS is explained in section Detailed usage in the context of PBB-VPLS is explained in section
4.2. 4.2.
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 MAC Flush TLV SHOULD be placed after the existing TLVs in MAC The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC
Flush message in [RFC4762]. Flush message in [RFC4762].
4.1.2. Application of MAC Flush TLV in Optimized MAC Flush 5.1.2. Application of MAC Flush TLV in Optimized MAC Flush
For optimized MAC flush, the MAC Flush TLV MAY be sent as in existing For optimized MAC flush, the MAC Flush TLV MAY be sent as in existing
LDP Address Withdraw Message with empty MAC List but from the core LDP Address Withdraw Message with empty MAC List but from the core
PE-rs on detection of failure of its local/primary spoke PW. The N PE-rs on detection of failure of its local/primary spoke PW. The N
bit in TLV MUST be set to 1 to indicate Flush-all-from-me. If the bit in TLV MUST be set to 1 to indicate Flush-all-from-me. If the
optimized MAC Flush procedure is used in a Backbone VPLS or regular 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 VPLS/H-VPLS context the C bit MUST be ZERO (C=0). If it is used in
an I-component context the C bit MUST be set (C= 1). See section 4.2 an I-component context the C bit MUST be set (C= 1). See section 4.2
for details of its usage in PBB-VPLS context. for details of its usage in PBB-VPLS context.
skipping to change at page 14, line 45 skipping to change at page 15, line 46
The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs
SHOULD be sent in cases where the network is being upgraded and SHOULD be sent in cases where the network is being upgraded and
devices are not capable of understanding the optimized MAC flush. devices are not capable of understanding the optimized MAC flush.
This would result in the same flushing action as [RFC4762] at the This would result in the same flushing action as [RFC4762] at the
receiving PE-rs devices. receiving PE-rs devices.
For the case of B-VPLS devices optimized MAC flush message SHOULD be For the case of B-VPLS devices optimized MAC flush message SHOULD be
supported. supported.
4.1.3. MAC Flush TLV Processing Rules for Regular VPLS 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS
This section describes the processing rules of MAC Flush TLV that This section describes the processing rules of MAC Flush TLV that
SHOULD be followed in the context of MAC flush procedures in VPLS. SHOULD be followed in the context of MAC flush procedures in VPLS.
For optimized MAC Flush a multi-homing PE-rs initiates MAC flush For optimized MAC Flush a multi-homing PE-rs initiates MAC flush
message towards the other related VPLS PE-rs devices when it detects message towards the other related VPLS PE-rs devices when it detects
a transition (failure or to standby) in its active spoke PW. In such a transition (failure or to standby) in its active spoke PW. In such
case the MAC Flush TLV MUST be sent with N= 1. A PE-rs device case the MAC Flush TLV MUST be sent with N= 1. A PE-rs device
receiving the MAC Flush TLV SHOULD follow the same processing rules receiving the MAC Flush TLV SHOULD follow the same processing rules
as described in this section. as described in this section.
skipping to change at page 15, line 29 skipping to change at page 16, line 31
then the receiving PE-rs SHOULD flush the MAC addresses learned from then the receiving PE-rs SHOULD flush the MAC addresses learned from
all PWs in the VPLS instance except the ones learned over the PW on all PWs in the VPLS instance except the ones learned over the PW on
which the message is received. which the message is received.
If a PE-rs device receives a MAC flush with the MAC Flush TLV option If a PE-rs device receives a MAC flush with the MAC Flush TLV option
and a valid MAC address list, it SHOULD ignore the option and deal and a valid MAC address list, it SHOULD ignore the option and deal
with MAC addresses explicitly as per [RFC4762]. It is assumed when with MAC addresses explicitly as per [RFC4762]. It is assumed when
these procedures are used all nodes support the MAC Flush Message. these procedures are used all nodes support the MAC Flush Message.
See section 5 Operational Considerations for details. See section 5 Operational Considerations for details.
4.1.4. Optimized MAC Flush Procedures 5.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 2. When the primary spoke PW transition (failure scenario in Figure 2. When the primary spoke PW transition (failure
or standby transition) is detected by PE1-rs, it MAY send MAC flush or standby transition) is detected by PE1-rs, it MAY send MAC flush
messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N = 1. messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N = 1.
Upon receipt of the MAC flush message, PE2-rs identifies the VPLS Upon receipt of the MAC flush message, PE2-rs identifies the VPLS
instance that requires MAC flush from the FEC element in the FEC TLV. instance that requires MAC flush from the FEC element in the FEC TLV.
On receiving N=1, PE-2 removes all MAC addresses learned from that PW On receiving N=1, PE-2 removes all MAC addresses learned from that PW
over which the message is received. The same action is followed by over which the message is received. The same action is followed by
PE3-rs and PE4-rs. PE3-rs and PE4-rs.
Figure 4 shows another redundant H-VPLS topology to protect against Figure 4 shows another redundant H-VPLS topology to protect against
failure of MTU-s device. Provider RSTP [IEEE.802.1Q-2011] may be failure of MTU-s device. Provider RSTP [IEEE.802.1Q-2011] may be
used as selection algorithm for active and backup PWs in order to used as selection algorithm for active and backup PWs in order to
maintain the connectivity between MTU-s devices and PE-rs devices at maintain the connectivity between MTU-s devices and PE-rs devices at
the edge. It is assumed that PE-rs devices can detect failure on PWs the edge. It is assumed that PE-rs devices can detect failure on PWs
in either direction through OAM mechanisms such as VCCV procedures in either direction through OAM mechanisms such as VCCV procedures
for instance. for instance.
MTU-1================PE-1===============PE-3 MTU-1================PE-1-rs=============PE-3-rs
|| || \ /|| || || \ /||
|| Redundancy || \ / || || Redundancy || \ / ||
|| Provider RSTP || Full-Mesh . || || Provider RSTP || Full-Mesh . ||
|| || / \ || || || / \ ||
|| || / \|| || || / \||
MTU-2----------------PE-2===============PE-4 MTU-2----------------PE-2-rs=============PE-4-rs
Backup PW Backup PW
Figure 4: Redundancy with Provider RSTP Figure 4: Redundancy with Provider RSTP
MTU-1, MTU-2, PE1-rs and PE2-rs participate in provider RSTP. By MTU-1, MTU-2, PE1-rs and PE2-rs participate in provider RSTP. By
configuration in RSTP it is ensured that the PW between MTU-1 and configuration in RSTP it is ensured that the PW between MTU-1 and
PE1-rs is active and the PW between MTU-2 and PE2-rs is blocked (made PE1-rs is active and the PW between MTU-2 and PE2-rs is blocked (made
backup) at MTU-2 end. When the active PW failure is detected by backup) at MTU-2 end. When the active PW failure is detected by
RSTP, it activates the PW between MTU-2 and PE2-rs. When PE1-rs RSTP, it activates the PW between MTU-2 and PE2-rs. When PE1-rs
detects the failing PW to MTU-1, it MAY trigger MAC flush into the detects the failing PW to MTU-1, it MAY trigger MAC flush into the
skipping to change at page 16, line 44 skipping to change at page 17, line 44
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 Further, the procedures are applicable with any native Ethernet
access topologies multi-homed to two or more VPLS PE-rs devices. The access topologies multi-homed to two or more VPLS PE-rs devices. The
text in this section applies for the native Ethernet case where text in this section applies for the native Ethernet case where
active/standby PWs are replaced with the active/standby Ethernet active/standby PWs are replaced with the active/standby Ethernet
endpoints. An optimized MAC Flush message can be generated by the endpoints. An optimized MAC Flush message can be generated by the
VPLS PE-rs that detects the failure in the primary Ethernet access. VPLS PE-rs that detects the failure in the primary Ethernet access.
4.2. LDP MAC Flush Extensions for PBB-VPLS 5.2. LDP MAC Flush Extensions for PBB-VPLS
The use of Address Withdraw message with MAC List TLV is proposed in The use of Address Withdraw message with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result [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-rs of a topology change (e.g. failure of a primary link of a VPLS PE-rs
device and implicitly the activation of an alternate link in a dual- device and implicitly the activation of an alternate link in a dual-
homing use case). These existing procedures apply individually to homing use case). These existing procedures apply individually to
B-VPLS and I-component domains. B-VPLS and I-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
skipping to change at page 17, line 49 skipping to change at page 18, line 49
Type: 0x02, IANA TBA Type: 0x02, IANA TBA
Length: value length in octets. Zero indicates an empty ISID list. Length: value length in octets. Zero indicates an empty ISID list.
An empty ISID list means that the flush applies to all the ISIDs An empty ISID list means that the flush applies to all the ISIDs
mapped to the B-VPLS indicated by the FEC TLV. mapped 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.1. MAC Flush TLV Processing Rules for PBB-VPLS 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS
The following steps describe the details of the processing rules for The following steps describe the details of the processing rules for
MAC Flush TLV in the context of PBB-VPLS: MAC Flush TLV in the context of PBB-VPLS:
The MAC Flush can be for the B-VPLS B-component (which applies to the The MAC Flush can be for the B-VPLS B-component (which applies to the
BMACs and the corresponding CMACs) or the B-VPLS I-component (which BMACs and the corresponding CMACs) or the B-VPLS I-component (which
applies to the CMACs) which is described in more detail here. applies to the CMACs) which is described in more detail here.
- The MAC Flush Message, including the MAC Flush Parameters TLV is - The MAC Flush Message, including the MAC Flush Parameters TLV is
initiated by the PBB PE(s) experiencing a Topology Change event in initiated by the PBB PE(s) experiencing a Topology Change event in
skipping to change at page 19, line 9 skipping to change at page 20, line 9
- N=0, all the CMACs in the selected ISID FIBs SHOULD be flushed with - N=0, all the CMACs in the selected ISID FIBs SHOULD be flushed with
the exception of the resulted CMAC list from the BMAC List mentioned the exception of the resulted CMAC list from the BMAC List mentioned
in the message. ("Flush all but the CMACs associated with the in the message. ("Flush all but the CMACs associated with the
BMAC(s) in the BMAC List Sub-TLV from the FIBs associated with the BMAC(s) in the BMAC List Sub-TLV from the FIBs associated with the
ISID list"). ISID list").
- N=1, all the resulted CMACs SHOULD be flushed ("Flush all the CMACs - N=1, all the resulted CMACs SHOULD be flushed ("Flush all the CMACs
associated with the BMAC(s) in the BMAC List Sub-TLV from the FIBs associated with the BMAC(s) in the BMAC List Sub-TLV from the FIBs
associated with the ISID list"). associated with the ISID list").
4.2.2. Applicability of MAC Flush Parameters TLV 5.2.2. Applicability of MAC Flush Parameters TLV
If MAC Flush Parameters TLV is received by a BEB in a PBB-VPLS that If MAC Flush Parameters TLV is received by a Backbone Edge Bridges
does not understand the TLV then it may result in undesirable MAC (BEB) in a PBB-VPLS that does not understand the TLV then it may
flushing action. It is RECOMMENDED that all PE-rs devices result in undesirable MAC flushing action. It is RECOMMENDED that
participating in PBB-VPLS support MAC Flush Parameters TLV. If this all PE-rs devices participating in PBB-VPLS support MAC Flush
is not possible the MAC Flush Parameters TLV SHOULD be disabled as Parameters TLV. If this is not possible the MAC Flush Parameters TLV
mentioned in section 5 Operational Considerations. SHOULD be disabled as mentioned in section 5 Operational
Considerations.
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 as explained in section 3.1.1. To achieve negative context as well as explained in section 3.1.1. To achieve negative
MAC Flush (flush-all-from-me) in regular VPLS context, the MAC Flush 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 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 of any Sub-TLVs. Negative MAC flush is highly desirable in scenarios
when VPLS access redundancy is provided by Ethernet Ring Protection when VPLS access redundancy is provided by Ethernet Ring Protection
as specified in ITU-T [ITU.G8032]specification etc. as specified in ITU-T [ITU.G8032]specification.
5. Operational Considerations 6. Operational Considerations
As mentioned before, if MAC Flush Parameters TLV is not understood by As mentioned before, if MAC Flush Parameters TLV is not understood by
a receiver then it would result in undesired flushing action. To a receiver then it would result in undesired flushing action. To
avoid this one solution is to develop an LDP based capability avoid this one solution is to develop an LDP based capability
negotiation mechanism to negotiate support of various MAC Flushing negotiation mechanism to negotiate support of various MAC Flushing
capability between PE-rs devices in a VPLS instance. A negotiation capability between PE-rs devices in a VPLS instance. A negotiation
mechanism is outside the scope of this document but is not required mechanism is outside the scope of this document but is not required
to deploy this optimized MAC flush as described below. to deploy this optimized MAC flush as described below.
VPLS may be used with or without the optimization. For the case of VPLS may be used with or without the optimization. For the case of
PBB-VPLS this operation is the only method supported for ISIDs. If PBB-VPLS this operation is the only method supported for ISIDs. If
an operator wants the optimizations for VPLS it is the operators an operator wants the optimizations for VPLS it is the operator's
responsibility to make sure the VPLS that are capable of supporting responsibility to make sure the VPLS that are capable of supporting
the optimization are properly configured. From operational the optimization are properly configured. From operational
standpoint, it is RECOMMENDED that implementations of the solution standpoint, it is RECOMMENDED that implementations of the solution
provide administrative control to select the desired MAC Flushing provide administrative control to select the desired MAC Flushing
action towards a PE-rs device in the VPLS. Thus in the topology action towards a PE-rs device in the VPLS. Thus in the topology
figure 2. it is possible that PE1-rs would initiate optimized MAC described in figure 2, it is possible that PE1-rs would initiate
Flush towards the PE-rs devices that supports the solution , whereas optimized MAC Flush towards the PE-rs devices that support the
PE2-rs would initiate [RFC4762] style of MAC Flush towards the PE-rs solution whereas PE2-rs would initiate [RFC4762] style of MAC Flush
devices that does not support the optimized solution. The PE-rs that towards the PE-rs devices that do not support the optimized solution.
supports the MAC Flush Parameters TLV MUST support the RFC4762 MAC The PE-rs that supports the MAC Flush Parameters TLV MUST support the
flush procedure for completeness. RFC4762 MAC flush procedure for completeness.
6. IANA Considerations 7. IANA Considerations
This document requests code point for following LDP TLV: This document requests code point for following LDP TLV:
o MAC Flush Parameters TLV. o MAC Flush Parameters TLV.
Also this document requests two Sub-TLV values for Also this document requests two Sub-TLV values for
o PBB BMAC List Sub-TLV 0x01 IANA TBA o PBB BMAC List Sub-TLV 0x01 IANA TBA
o PBB ISID List Sub-TLV 0x02 IANA TBA o PBB ISID List Sub-TLV 0x02 IANA TBA
7. Security Considerations 8. 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.
8. Contributing Authors 9. Contributing Authors
The authors would like to thank Marc Lasserre and Don Fedyk who made The authors would like to thank Marc Lasserre and Don Fedyk who made
a major contribution to the development of this document. a major contribution to the development of this document.
Marc Lasserre Marc Lasserre
Alcatel-Lucent Alcatel-Lucent
Email: marc.lasserre@alcatel-lucent.com Email: marc.lasserre@alcatel-lucent.com
Don Fedyk Don Fedyk
Hewlett-Packard Company Hewlett-Packard Company
Email: don.fedyk@hp.com Email: don.fedyk@hp.com
9. Acknowledgements 10. Acknowledgements
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: Dimitri Papadimitriou, Jorge Rabadan, Prashanth this document: Dimitri Papadimitriou, Jorge Rabadan, Prashanth
Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul
Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar and Giles Heron. Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar and Giles Heron.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
10.2. Informative References 11.2. Informative References
[RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the [RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the
Virtual Private LAN Service (VPLS) Provider Edge (PE) Virtual Private LAN Service (VPLS) Provider Edge (PE)
Model for Provider Backbone Bridging",RFC 7041, Model for Provider Backbone Bridging",RFC 7041,
November 2013. November 2013.
[I-D.ietf-l2vpn-vpls-multihoming] [I-D.ietf-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., Balus, F., Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
Palislamovic, S., Uttaro, J., and W. Lin, "BGP based Palislamovic, S., Uttaro, J., and W. Lin, "BGP based
Multi-homing in Virtual Private LAN Service", Multi-homing in Virtual Private LAN Service",
 End of changes. 51 change blocks. 
110 lines changed or deleted 117 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/