draft-ietf-l2vpn-vpls-ldp-mac-opt-08.txt   draft-ietf-l2vpn-vpls-ldp-mac-opt-09.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: August 29, 2013 O. Stokes Expires: May 31, 2014 O. Stokes
Extreme Networks Extreme Networks
G. Calvinac G. Calvinac
France Telecom France Telecom
February 25, 2013 November 27, 2013
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-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-09
Abstract Abstract
[RFC4762] describes a mechanism to remove or unlearn MAC addresses RFC4762 describes a mechanism to remove or unlearn MAC addresses that
that have been dynamically learned in a VPLS Instance for faster 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. This document defines an enhancement to the MAC topology change. This document defines an enhancement to the MAC
Address Withdrawal procedure with empty MAC List [RFC4762], which Address Withdrawal procedure with empty MAC List from RFC4762, which
enables a Provider Edge(PE) device to remove only the MAC addresses enables a Provider Edge(PE) device to remove only the MAC addresses
that need to be relearned. Additional extensions to [RFC4762] MAC that need to be relearned. Additional extensions to RFC4762 MAC
Withdrawal procedures are specified to provide optimized MAC flushing Withdrawal procedures are specified to provide optimized MAC flushing
for the PBB-VPLS specified in [I-D.ietf-l2vpn-pbb-vpls-pe-model] . for the PBB-VPLS specified in working group 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 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 August 29, 2013. 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) 2013 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 3, line 7 skipping to change at page 3, line 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Terminology 1. Terminology
This document uses the terminology defined in This document uses the terminology defined in [RFC7041], [RFC5036],
[I-D.ietf-l2vpn-pbb-vpls-pe-model], [RFC5036], [RFC4447] and [RFC4447] and [RFC4762].
[RFC4762].
Throughout this document VPLS means the emulated bridged LAN service Throughout this document VPLS means the emulated bridged LAN service
offered to a customer. H-VPLS means the hierarchical connectivity or offered to a customer. H-VPLS means the hierarchical connectivity or
layout of MTU-s and PE-rs devices offering the VPLS [RFC4762]. 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.
skipping to change at page 3, line 51 skipping to change at page 3, line 50
(PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh
topology provides a LAN segment or broadcast domain that is fully topology provides a LAN segment or broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses at the capable of learning and forwarding on Ethernet MAC addresses at the
PE devices. PE devices.
This VPLS full mesh core configuration can be augmented with This VPLS full mesh core configuration can be augmented with
additional non-meshed spoke nodes to provide a Hierarchical VPLS additional non-meshed spoke nodes to provide a Hierarchical VPLS
(H-VPLS) service [RFC4762]. Throughout this document this (H-VPLS) service [RFC4762]. Throughout this document this
configuration is referred to as "regular" H-VPLS. configuration is referred to as "regular" H-VPLS.
[I-D.ietf-l2vpn-pbb-vpls-pe-model] describes how Provider Backbone [RFC7041] describes how Provider Backbone Bridging (PBB) can be
Bridging (PBB) can be integrated with VPLS to allow for useful PBB integrated with VPLS to allow for useful PBB capabilities while
capabilities while continuing to avoid the use of MSTP in the continuing to avoid the use of MSTP in the backbone. The combined
backbone. The combined solution referred to as PBB-VPLS results in solution referred to as PBB-VPLS results in better scalability in
better scalability in terms of number of service instances, PWs and terms of number of service instances, PWs and C-MAC (Customer MAC)
C-MAC (Customer MAC) Addresses that need to be handled in the VPLS Addresses that need to be handled in the VPLS PEs depending on the
PEs depending on the location of the I-component in the PBB-VPLS location of the I-component in the PBB-VPLS topology.
topology.
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. Note that the H-VPLS topology change in resilient H-VPLS topologies. Note that the H-VPLS topology
in [RFC4762] describes two tier hierarchy to VPLS as the basic in [RFC4762] describes two tier hierarchy to VPLS as the basic
building block of H-VPLS, but it is possible to have multi-tier building block of H-VPLS, but it is possible to have multi-tier
hierarchy in an H-VPLS. hierarchy in an H-VPLS.
The figure 1. described below is taken from [RFC4762] that describes The figure 1. described below is taken from [RFC4762] that describes
dual-homing in H-VPLS. dual-homing in H-VPLS.
skipping to change at page 5, line 33 skipping to change at page 5, line 31
Address Withdraw Message from the PE that is no longer connected to Address Withdraw Message from the PE that is no longer connected to
the MTU-s with the primary PW, with the list of MAC addresses to be the MTU-s with the primary PW, with the list of MAC addresses to be
removed to all other PEs over the corresponding LDP sessions removed to all other PEs over the corresponding LDP sessions
[RFC4762]. [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. empty MAC List described in [RFC4762] unless specified otherwise. The
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.
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
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 for
the originating PE-rs. the originating PE-rs.
2.3. MAC Flush in PBB-VPLS 2.3. MAC Flush in PBB-VPLS
[I-D.ietf-l2vpn-pbb-vpls-pe-model] describes how PBB can be [RFC7041] describes how PBB can be integrated with VPLS to allow for
integrated with VPLS to allow for useful PBB capabilities while useful PBB capabilities while continuing to avoid the use of MSTP in
continuing to avoid the use of MSTP in the backbone. The combined the backbone. The combined solution referred to as "PBB-VPLS"
solution referred to as "PBB-VPLS" results in better scalability in results in better scalability in terms of number of service
terms of number of service instances, PWs and C-MACs that need to be instances, PWs and C-MACs that need to be handled in the VPLS PE-rs
handled in the VPLS PE-rs devices. This document describes devices. This document describes extensions to LDP MAC Flush
extensions to LDP MAC Flush procedures described in [RFC4762] procedures described in [RFC4762] required to build desirable
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 3. 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.
skipping to change at page 10, line 41 skipping to change at page 10, line 41
that will flush only the MAC addresses learned from the respective that will flush only the MAC addresses learned from the respective
PWs between PE1-rs and other PE devices in the full-mesh minimizing PWs between PE1-rs and other PE devices in the full-mesh minimizing
the relearning and flooding in the network. In the example above, the relearning and flooding in the network. In the example above,
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. other PE-rs devices is the same as in MTU-s initiated MAC Flush. This
This is the [RFC4762] specified behavior. is the [RFC4762] specified behavior.
3.1.2. MAC Flush Optimization for native Ethernet access 3.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
skipping to change at page 20, line 43 skipping to change at page 20, line 43
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
Alcatel-Lucent Hewlett-Packard Company
Email: donald.fedyk@alcatel-lucent.com Email: don.fedyk@hp.com
9. Acknowledgements 9. 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 10. References
skipping to change at page 21, line 29 skipping to change at page 21, line 29
[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 10.2. Informative References
[I-D.ietf-l2vpn-pbb-vpls-pe-model] [RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the
Balus, F., Sajassi, A., and N. Bitar, "Extensions to VPLS Virtual Private LAN Service (VPLS) Provider Edge (PE)
PE model for Provider Backbone Bridging", Model for Provider Backbone Bridging",RFC 7041,
draft-ietf-l2vpn-pbb-vpls-pe-model-06 (work in progress), November 2013.
October 2012.
[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",
draft-ietf-l2vpn-vpls-multihoming-04 (work in progress), draft-ietf-l2vpn-vpls-multihoming-06 (work in progress),
October 2012. October 2012.
[IEEE.802.1Q-2011] [IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual networks -- Media Access Control (MAC) Bridges and Virtual
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,
 End of changes. 17 change blocks. 
40 lines changed or deleted 37 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/