Internet DRAFT - draft-balus-l2vpn-pbb-ldp-ext
draft-balus-l2vpn-pbb-ldp-ext
L2VPN Working Group Florin Balus
Internet Draft Pranjal Kumar Dutta
Intended Status: Proposed Standard Alcatel-Lucent
Expires: September 2010
Geraldine Calvignac
France Telecom
Olen Stokes
Extreme Networks
March 8, 2010
Extensions to LDP MAC Withdraw for PBB-VPLS
draft-balus-l2vpn-pbb-ldp-ext-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Balus, et al. Expires September 8, 2010 [Page 1]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Extensions to VPLS PE model to accommodate PBB components where
discussed in [PBB-VPLS Model]. This draft discusses optional
extensions to the LDP Signaling procedures in [RFC4762] required to
further enhance the PBB-VPLS solution.
Table of Contents
1. Introduction...................................................2
2. General terminology............................................3
2.1. Conventions used in this document.........................4
3. PBB Blackholing issue..........................................4
4. Required Extensions to LDP MAC Withdraw........................5
5. Security Considerations........................................8
6. IANA Considerations............................................8
7. References.....................................................9
7.1. Normative References......................................9
7.2. Informative References....................................9
8. Acknowledgments................................................9
1. Introduction
[PBB-VPLS Model] describes how PBB can be integrated with VPLS to
allow for useful PBB capabilities while continuing to avoid the use
of MSTP in the backbone. The combined solution referred as PBB-VPLS
results in better scalability in terms of number of service
instances, PWs and C-MACs that need to be handled in the VPLS PEs.
This document describes optional extensions to LDP Signaling
procedures described in [RFC4762] required to add desirable
capabilities to PBB-VPLS solution.
Section 2 gives a quick terminology reference. Section 3 covers the
problem space. Section 4 describes the solution and required TLV
extensions.
Balus, et al. Expires September 8, 2010 [Page 2]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
2. General terminology
Some general terminology is defined here; most of the terminology
used is from [IEEE802.1ah], [RFC4762] and [RFC4026]. Terminology
specific to this memo is introduced as needed in later sections.
802.1ah: IEEE specification for "MAC tunneling" encapsulation and
bridging of frames across a provider backbone bridged network.
PBB: Provider Backbone Bridge
BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It can contain an I-component, B-component
or both I and B components.
BCB: A backbone core bridge positioned at the core of a provider
backbone bridged network. It contains only B-component.
B-TAG: field defined in the 802.1ah provider MAC encapsulation
header that conveys the backbone VLAN identifier information. The
format of the B-TAG field is the same as that of an 802.1ad S-TAG
field.
B-MAC: The backbone source or destination MAC address fields defined
in the 802.1ah provider MAC encapsulation header.
B-component, referred here also as B-VPLS: A bridging component
contained in BEBs and BCBs that bridges in the provider backbone
space based on B-MAC and B-TAG information
I-TAG: A field defined in the 802.1ah provider MAC encapsulation
header that conveys the service instance information (I-SID)
associated with the frame.
I-SID: The 24-bit service instance field carried inside the I-TAG. I-
SID defines the service instance that the frame should be "mapped
to".
S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
conveys the service VLAN identifier information (S-VLAN).
S-VLAN: The specific service VLAN identifier carried inside an S-TAG
I-component: A bridging component contained in a backbone edge bridge
Balus, et al. Expires September 8, 2010 [Page 3]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
that bridges in the customer space based on customer MAC addresses
and S-TAG information
2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
3. PBB Blackholing issue
In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as
infrastructure for one or more I-component instances. B-VPLS control
plane (LDP Signaling) replaces I-component control plane throughout
the MPLS core. This is raising an additional challenge related to
blackhole avoidance in the I-component domain as described in this
section. Figure 1 describes the case of a CE device (node A) dual-
homed to two I-component instances located on two PBB-VPLS PEs (PE1
and PE2).
IP/MPLS Core
+--------------+
|PE2 |
+----+ |
|PBB | +-+ |
_ |VPLS|---|P| |
S/+----+ /+-+\ |PE3
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
+---+ A +----+ +-+ +----+ +---+
A |PE1 | B
| |
+--------------+
Figure 1: PBB Blackholing Issue - CE Dual-Homing use case
The link between PE1 and CE A is active (marked with A) while the
link between CE A and PE2 is in Standby/Blocked status. In the
network diagram CMAC X is one of the MAC addresses located behind CE
A in the customer domain, CMAC Y is behind CE B and the BVPLS
instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2
with BMAC B2.
Balus, et al. Expires September 8, 2010 [Page 4]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the
remote PEs participating in the IVPLS (for example, PE3) will learn
the CMAC X associated with BMAC B1 on PE1. Under failure of the link
between CE A and PE1 and activation of link to PE2, the remote PEs
(for example, PE3) will black-hole the traffic destined for customer
MAC X to BMAC B1 until the aging timer expires or a packet flows from
X to Y through the PE B2. This may take a long 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
Flush as specified in [RFC4762] to flush in the BVPLS domain the BMAC
associated with the PE where the failure occurred. This will
automatically flush the CMAC to BMAC association in the remote PEs.
This solution though has the disadvantage of producing a lot of
unnecessary MAC flush in the B-VPLS domain as there was no failure or
topology change affecting the Backbone domain.
A better solution is required to propagate the I-component events
through the backbone infrastructure (B-VPLS) in order to flush only
the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there
are no IVPLS control plane exchanges across the PBB backbone,
extensions to B-VPLS control plane are required to propagate the I-
component MAC Flush events across the B-VPLS.
4. Required Extensions to LDP MAC Withdraw
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
of a topology change (e.g. failure of a primary link of a VPLS PE and
implicitly the activation of an alternate link in a dual-homing use
case). These existing procedures apply individually to B-VPLS and I-
component domains.
When it comes to reflecting topology changes in access networks
connected to I-component across the B-VPLS domain certain additions
should be considered as described below.
MAC Switching in PBB is based on the mapping of Customer MACs (CMACs)
to Backbone MAC(s) (BMACs). A topology change in the access (I-
domain) should just invoke the flushing of CMAC entries in PBB PEs'
FIB(s) associated with the I-component(s) impacted by the failure.
There is a need to indicate the PBB PE (BMAC source) that originated
the MAC Flush message.
Balus, et al. Expires September 8, 2010 [Page 5]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
These goals can be achieved by adding a new MAC Flush Parameters TLV
in the LDP Address Withdraw message to indicate the particular
domain(s) requiring MAC flush. At the other end, the receiving PEs
may use the information from the new TLV to flush only the related
FIB entry/entries in the I-component instance(s).
A suggested structure for MAC Flush Parameters TLV is depicted below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| MAC Flush Params TLV(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UF bits are set to forward unknown so that potential intermediate
VPLS PEs unaware of the new TLV can just propagate it transparently.
The MAC Flush Parameters TLV type value is to be assigned by IANA.
The Length field is used to define the length of the TLV including
the type and the length itself. The TLV value field contains an one
byte Flag field used as described below. A number of sub-TLVs may be
also defined inside the TLV value field. Any sub-TLV definition to
the above TLV MUST address the actions in combination with other
existing sub-TLVs.
The detailed format for the Flags bit vector is described below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|N| MBZ | (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
1 Byte Flag field is mandatory. The following flags are defined:
C flag, used to indicate whether the MAC Flush is required in the
FIB associated with the VPLS context in which LDP MAC Flush was
received. For PBB-VPLS this is called Backbone VPLS. C flag MUST be
ZERO (C=0) when a MAC Flush for the Backbone VPLS (B-component
VPLS) is required. C flag MUST be set (C=1) when the MAC Flush for
Customer VPLS (I-component VPLS) is required.
Balus, et al. Expires September 8, 2010 [Page 6]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
N flag, used to indicate whether a positive (N=0, Flush-all-but-
mine) or negative (N=1 Flush-all-from-me) MAC Flush is required.
The source (mine/me) is defined either as the PW associated with
the LDP session on which the LDP MAC Withdraw was received or with
the BMAC(s) listed in the BMAC Sub-TLV.
MBZ flags, the rest of the flags should be set to zero on
transmission and ignored on reception.
The following sub-TLVs MUST be included in the MAC Flush Parameters
TLV if the C-flag is set:
- PBB BMAC List sub-TLV:
Type: 0x01
Length: value length in octets. At least one BMAC address must be
present in the list.
Value: one or a list of 48 bits BMAC addresses. These are the source
BMAC addresses associated with the B-VPLS instance that originated
the MAC Withdraw message. It will be used to identify the CMAC(s)
mapped to the BMAC(s) listed in the sub-TLV.
- PBB ISID List sub-TLV:
Type: 0x02,
Length: value length in octets. Zero indicates an empty ISID list. An
empty ISID list means that the flush applies to all the ISIDs mapped
to the B-VPLS indicated by the FEC TLV.
Value: one or a list of 24 bits ISIDs that represent the I-component
FIB(s) where the MAC Flush needs to take place.
The following steps describe the details of the processing for the
related LDP Address Withdraw message:
. The LDP MAC Withdraw Message, including the MAC Flush Parameters
TLV is initiated by the PBB PE(s) experiencing a Topology Change
event in one or multiple customer I-component(s).
o The flags are set accordingly to indicate the type of MAC
Flush required for this event: N=0 (Flush-all-but-mine),
C=1 (Flush only CMAC FIBs).
o The PBB Sub-TLVs (BMAC and ISID Lists) are included
Balus, et al. Expires September 8, 2010 [Page 7]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
. On reception of the LDP message, the B-VPLS instances related to
the FEC TLV from the LDP Address Withdraw message must interpret
the content of MAC Flush Parameters TLV. If the C-bit is set the
BCBs should not flush their BMAC FIBs. The B-VPLS control plane
may propagate the MAC Flush indication following the split-horizon
grouping and the established BVPLS topology.
. The receiving BEBs use the sub-TLVs from the MAC Flush Parameters
TLV as follows:
o The PBB ISID List is used to determine the particular ISID
FIBs that need to be flushed. If the ISID List is empty all
the ISID FIBs associated with the receiving B-VPLS are
flushed.
o The PBB BMAC List is used to identify from the ISID FIBs
selected in the previous step just the entries that map
CMACs to the BMACs that are not listed in the sub-TLV.
. Next, depending on the N flag value the following actions apply:
o N=0, all the CMACs in the selected ISID FIBs should be
flushed with the exception of the resulted CMAC list
("Flush all but the CMACs associated with the BMAC(s) in
the BMAC List Sub-TLV from the FIBs associated with the
ISID list").
o N=1, the resulted CMAC list should be flushed ("Flush all
the CMACs associated with the BMAC(s) in the BMAC List Sub-
TLV from the FIBs associated with the ISID list")
5. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4762].
6. IANA Considerations
IANA needs to assign MAC Flush Parameters TLV type values.
Balus, et al. Expires September 8, 2010 [Page 8]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
7.2. Informative References
[IEEE802.1ah] IEEE 802.1ah "Virtual Bridged Local Area Networks,
Amendment 6: Provider Backbone Bridges", Approved Standard
June 12th, 2008
[RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private
Network (VPN) Terminology", RFC 4026, March 2005.
[PBB-VPLS Model] F. Balus, et Al. "Extensions to VPLS PE model for
Provider Backbone Bridging", draft-ietf-l2vpn-pbb-vpls-pe-
model-00.txt, May 2009 (work in progress)
8. Acknowledgments
The authors would like to thank Wim Henderickx, Dimitri
Papadimitriou, Jorge Rabadan and Maarten Vissers for their insightful
comments and probing questions.
Balus, et al. Expires September 8, 2010 [Page 9]
Internet-Draft Extensions to LDP MAC Withdraw for PBB-VPLS March 2010
Authors' Addresses
Dutta Kumar Pranjal
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: dutta.pranjal@alcatel-lucent.com
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Geraldine Calvignac
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange-ftgroup.com
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
Email: ostokes@extremenetworks.com
Balus, et al. Expires September 8, 2010 [Page 10]
