draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-13.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: December 5, 2014 O. Stokes Expires: December 29, 2014 O. Stokes
Extreme Networks Extreme Networks
G. Calvignac G. Calvignac
Orange Orange
D. Fedyk D. Fedyk
Hewlett-Packard Hewlett-Packard
June 3, 2014 June 27, 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-12 draft-ietf-l2vpn-vpls-ldp-mac-opt-13
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 Virtual Private LAN Service (VPLS) have been dynamically learned in a Virtual Private LAN Service (VPLS)
Instance for faster convergence on topology change. The procedure Instance for faster convergence on topology change. The procedure
also removes MAC addresses in the VPLS that do not require relearning also removes MAC addresses in the VPLS that do not require relearning
due to such topology change. This document defines an enhancement to due to such topology change. This document defines an enhancement to
the MAC Address Withdrawal procedure with empty MAC List from the MAC Address Withdrawal procedure with empty MAC List from
RFC4762, which enables a Provider Edge(PE) device to remove only the RFC4762, which enables a Provider Edge(PE) device to remove only the
skipping to change at page 5, line 36 skipping to change at page 5, line 36
/ \ | | / \ | |
CE-2 \ | -- | CE-2 \ | -- |
\ Secondary PW | / \ | \ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / | - - - - - - - - - - - - - - - - - | \S / |
| -- | | -- |
+--------+ +--------+
PE3-rs PE3-rs
Figure 1: An example of a dual-homed MTU-s Figure 1: An example of a dual-homed MTU-s
An example usage of the MAC Flush mechanism is the dual-homed H-VPLS An example usage of the MAC Flush mechanism is the dual-homed H-VPLS
where an edge device termed as MTU-s is connected to two PE devices where an edge device termed as Multi Tenant Unit switch (MTU-
via primary spoke PW and backup spoke PW respectively. Such s)[RFC4762], is connected to two PE devices via primary spoke PW and
redundancy is designed to protect against the failure of primary backup spoke PW respectively. Such redundancy is designed to protect
spoke PW or primary PE device. There could be multiple methods of against the failure of primary spoke PW or primary PE device. There
dual homing in H-VPLS that are not described in [RFC4762]. For could be multiple methods of dual homing in H-VPLS that are not
example, note the following statement from section 10.2.1 in described in [RFC4762]. For example, note the following statement
[RFC4762]. from section 10.2.1 in [RFC4762].
"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.
2. Terminology 2. Terminology
skipping to change at page 6, line 41 skipping to change at page 6, line 41
In general, "MAC Flush" means the method of initiating and processing In general, "MAC Flush" means the method of initiating and processing
of MAC Flush Messages across a VPLS instance. of MAC Flush Messages across a VPLS instance.
3. Overview 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 Virtual Switch flush the MAC addresses learned in the corresponding Virtual Switch
Instance (VSI) in peer PE devices participating in the full mesh, to Instance (VSI) in peer PE devices participating in the full mesh, to
avoid black holing of frames to those addresses. This is avoid black holing of frames to those addresses. This is
accomplished by sending an LDP Address Withdraw Message from the PE accomplished by sending an LDP Address Withdraw Message, a new
that is no longer connected to the MTU-s with the primary PW, with message defined in this document, from the PE that is no longer
the list of MAC addresses to be removed to all other PEs over the connected to the MTU-s with the primary PW. The new message has the
corresponding LDP sessions [RFC4762]. list of MAC addresses to be removed to all other PEs over the
corresponding LDP sessions.
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. When a PE-rs switch in the full-mesh of H-
Message" is used to specify LDP Address Withdraw Message with an VPLS receive this message it also flushes MAC addresses which are not
empty MAC List described in [RFC4762]. The solutions described in affected due to topology change, thus leading to unnecessary flooding
this document are applicable only to LDP Address Withdraw Message and relearning. Throughout this document the term "MAC Flush Message"
with empty MAC List. is used to specify LDP Address Withdraw Message with an empty MAC
List described in [RFC4762]. The solutions described in this document
are applicable only to LDP Address Withdraw Message with empty MAC
List.
In a VPLS topology, the core PWs remain active and learning happens In a VPLS topology, the core PWs remain active and learning happens
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-
skipping to change at page 9, line 8 skipping to change at page 9, line 8
The MAC Flush information is propagated in the control plane. The The MAC Flush information is propagated in the control plane. The
control plane message propagation is associated with the data path control plane message propagation is associated with the data path
and hence follows similar rules for propagation as the forwarding in and hence follows similar rules for propagation as the forwarding in
the LDP data plane. For example PE-rs nodes follow the data plane the LDP data plane. For example PE-rs nodes follow the data plane
"split-horizon" forwarding rules in H-VPLS (Refer to section 4.4 in "split-horizon" forwarding rules in H-VPLS (Refer to section 4.4 in
[RFC4762]). Therefore a MAC Flush is propagated in the context of [RFC4762]). Therefore a MAC Flush is propagated in the context of
mesh PW(s) when it is received in the context of a spoke PW. When a mesh PW(s) when it is received in the context of a spoke PW. When a
PE-rs node receives a MAC Flush in the context of a mesh PW then it PE-rs node receives a MAC Flush in the context of a mesh PW then it
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,
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
topology change, thus leading to unnecessary flooding and relearning.
This document describes an optional mechanism to augment the MAC
flush procedure in [RFC4762] so that it flushes only the set of MAC
addresses that require relearning when topology changes in H-VPLS.
3.2. MAC Flush on failure 3.2. MAC Flush on failure
MAC Flush on failure or "negative" MAC flush is introduced in this MAC Flush on failure or "negative" MAC flush is introduced in this
document. Negative MAC flush is an improvement on the current document. Negative MAC flush is an improvement on the current
practice of sending a MAC Flush Message with an empty MAC list practice of sending a MAC Flush Message with an empty MAC list
described in section 3.1.1. We use the term "negative" MAC flush or described in section 3.1.1. We use the term "negative" MAC flush or
"Flush-all-from-me" for this kind of flushing action as opposed to "Flush-all-from-me" for this kind of flushing action as opposed to
"positive" MAC Flush action in [RFC4762]. In negative MAC flush, the "positive" MAC Flush action in [RFC4762]. In negative MAC flush, the
MAC Flush is initiated by PE1-rs (Figure 1) on detection of failure MAC Flush is initiated by PE1-rs (Figure 1) on detection of failure
of the primary spoke PW. The MAC Flush is sent to all participating of the primary spoke PW. The MAC Flush is sent to all participating
skipping to change at page 10, line 15 skipping to change at page 10, line 7
[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 Multi Segment Pseudowires (MS-PW)s are used in interconnecting when Multi Segment Pseudowires (MS-PW)s [RFC6073] are used in
PE devices in H-VPLS. There could be other H-VPLS models not defined interconnecting PE devices in H-VPLS. There could be other H-VPLS
in this document where the solution may be applicable. models not defined in this document where the solution may be
applicable.
4. Problem Description 4. Problem Description
This section describes the problems in detail with respective to This section describes the problems in detail with respective to
various MAC flush actions described in section 3. various MAC flush actions described in section 3.
4.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
skipping to change at page 22, line 22 skipping to change at page 22, line 21
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. as specified in ITU-T [ITU.G8032]specification.
6. Operational Considerations 6. Operational Considerations
As mentioned before, if the MAC Flush Parameters TLV is not As mentioned earlier, if the MAC Flush Parameters TLV is not
understood by a receiver then it would result in undesired flushing understood by a receiver then it would result in undesired flushing
action. To avoid this one solution is to develop an LDP based action. To avoid this, one possible solution is to develop an LDP
capability negotiation mechanism to negotiate support of various MAC based capability negotiation mechanism to negotiate support of
Flushing capability between PE-rs devices in a VPLS instance. A various MAC Flushing capability between PE-rs devices in a VPLS
negotiation mechanism is outside the scope of this document but is instance. A negotiation mechanism was discussed and was considered
not required to deploy this optimized MAC flush as described below. outside the scope of this document. Negotiation is not required to
deploy this optimized MAC flush as described in this document.
VPLS may be used with or without the optimization. If an operator VPLS may be used with or without the optimization. If an operator
wants the optimizations for VPLS it is the operator's responsibility wants the optimizations for VPLS it is the operator's responsibility
to make sure the VPLS that are capable of supporting the optimization to make sure the VPLS that are capable of supporting the optimization
are properly configured. From operational standpoint, it is are properly configured. From operational standpoint, it is
RECOMMENDED that implementations of the solution provide RECOMMENDED that implementations of the solution provide
administrative control to select the desired MAC Flushing action administrative control to select the desired MAC Flushing action
towards a PE-rs device in the VPLS. Thus in the topology described towards a PE-rs device in the VPLS. Thus in the topology described
in figure 2, an implementation could support PE1-rs sending optimized in figure 2, an implementation could support PE1-rs sending optimized
MAC Flush towards the PE-rs devices that support the solution and MAC Flush towards the PE-rs devices that support the solution and
skipping to change at page 24, line 19 skipping to change at page 24, line 19
Marc Lasserre Marc Lasserre
Alcatel-Lucent Alcatel-Lucent
Email: marc.lasserre@alcatel-lucent.com Email: marc.lasserre@alcatel-lucent.com
10. 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, feedback and review on the topics
this document: Dimitri Papadimitriou, Jorge Rabadan, Prashanth discussed in this document: Dimitri Papadimitriou, Jorge Rabadan,
Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim
Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar, Giles Heron, Adrian Henderickx, Paul Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar,
Farrel, Ben Niven-Jenkins, Robert Sparks and Susan Hares. Giles Heron, Adrian Farrel, Ben Niven-Jenkins, Robert Sparks, Susan
Hares and Stephen Farrell.
11. References 11. References
11.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
skipping to change at page 25, line 23 skipping to change at page 25, line 25
Bridged Local Area Networks", IEEE Std 802.1Q, 2011. Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[ITU.G8032] [ITU.G8032]
International Telecommunications Union, "Ethernet ring International Telecommunications Union, "Ethernet ring
protection switching", ITU-T Recommendation G.8032, protection switching", ITU-T Recommendation G.8032,
March 2010. March 2010.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire [RFC6718] Muley, P., Aissaoui, M., and Bocci, M., "Pseudowire
Redundancy", RFC 6718, August 2012. Redundancy", RFC 6718, August 2012.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and
Aissaoui, M., "Segmented Pseudowire", RFC 6073, January
2011.
Authors' Addresses Authors' Addresses
Pranjal Kumar Dutta Pranjal Kumar Dutta
Alcatel-Lucent Alcatel-Lucent
701 E Middlefield Road 701 E Middlefield Road
Mountain View, California 94043 Mountain View, California 94043
USA USA
Email: pranjal.dutta@alcatel-lucent.com Email: pranjal.dutta@alcatel-lucent.com
 End of changes. 13 change blocks. 
42 lines changed or deleted 45 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/