One document matched: draft-kompella-l2vpn-vpls-multihoming-00.txt
Network Working Group K. Kompella
Internet-Draft B. Kothari
Updates: 4761 (if approved) Juniper Networks
Intended status: Standards Track T. Spencer
Expires: May 15, 2008 at&t
November 12, 2007
Multi-homing in BGP-based Virtual Private LAN Service
draft-kompella-l2vpn-vpls-multihoming-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kompella, et al. Expires May 15, 2008 [Page 1]
Internet-Draft BGP VPLS Multi-homing November 2007
Abstract
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo
shows how multi-homing can be offered in the context of BGP-based
VPLS.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 5
2.3. Using the Spanning Tree Protocol for Multi-homing . . . . 5
2.4. Active/Backup Links . . . . . . . . . . . . . . . . . . . 6
2.5. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. BGP Path Selection . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Bucketization . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Tie-breaking Rules . . . . . . . . . . . . . . . . . . 8
3.2. VPLS Path Selection . . . . . . . . . . . . . . . . . . . 8
3.2.1. Bucketization . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Tie-breaking Rules . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Kompella, et al. Expires May 15, 2008 [Page 2]
Internet-Draft BGP VPLS Multi-homing November 2007
1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing". [2]
explains how VPLS can be offered using BGP for auto-discovery and
signaling; section 3.5 of that document describes how multi-homing
can be achieved in this context. Implementation and deployment of
multi-homing in BGP-based VPLS has suggested some refinement of the
procedures described earlier; this memo details these changes.
Section 2 lays out some of the scenarios for multi-homing, other ways
that this can be achieved, and some of the expectations of BGP-based
multi-homing. Section 3 defines the components of BGP-based multi-
homing, and the procedures required to achieve this. Section 4 may
someday discuss security considerations.
1.1. General Terminology
Some general terminology is defined here; most is from [2] or [4].
Terminology specific to this memo is introduced as needed in later
sections.
A "Customer Edge" (CE) device, typically located on customer
premises, connects to a "Provider Edge" (PE) device, which is owned
and operated by the SP. A "Provider" (P) device is also owned and
operated by the SP, but has no direct customer connections. A "VPLS
Edge" (VE) device is a PE that offers VPLS services.
A VPLS domain represents a bridging domain per customer. A Route
Target community as described in [3] is typically used to identify
all the PE routers participating in a particular VPLS domain. A VPLS
site is a grouping of ports on a PE that belong to the same VPLS
domain. Sites are referred to as local or remote depending on
whether they are configured on the PE router in context or on one of
the remote PE routers (network peers).
1.2. Conventions
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 [1].
Kompella, et al. Expires May 15, 2008 [Page 3]
Internet-Draft BGP VPLS Multi-homing November 2007
2. Background
This section describes various scenarios where multi-homing may be
required, and the implications thereof. It also describes some of
the singular properties of VPLS multi-homing, and what that means
from both an operational point of view and an implementation point of
view. It describes briefly how the Spanning Tree Protocol can be
used to achieve multi-homing, and how that compares with BGP-based
multi-homing.
2.1. Scenarios
The most basic scenario is shown in Figure 1.
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
connectivity.
...............
. . ___ CE2
___ PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \___ CE3
\___ PE2 .
. .
...............
Figure 1: Scenario 1
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
connectivity. However, CE4, which is also in the same VPLS domain,
is single-homed to just PE1.
CE4 ------- ...............
\ . . ___ CE2
___ PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \___ CE3
\___ PE2 .
. .
...............
Figure 2: Scenario 2
Kompella, et al. Expires May 15, 2008 [Page 4]
Internet-Draft BGP VPLS Multi-homing November 2007
2.2. VPLS Multi-homing Considerations
The first (perhaps obvious) fact about a multi-homed VPLS CE, such as
CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a
loop has been created in the customer VPLS. This is a dangerous
situation for an Ethernet network, and the loop must be broken. Even
if CE1 is a router, it will get duplicates every time a packet is
flooded, which is clearly undesirable.
The next is that (unlike the case of IP-based multi-homing) only one
of PE1 and PE2 can be actively sending traffic, either towards CE1 or
into the SP cloud. That is to say, load balancing techniques will
not work. All other PEs MUST choose the same designated forwarder
for a multi-homed site. Call the PE that is chosen to send traffic
to/from CE1 the "designated forwarder".
In Figure 2, CE1 and CE4 must be dealt with independently, since CE1
is dual-homed, but CE4 is not.
2.3. Using the Spanning Tree Protocol for Multi-homing
It is quite common to have redundant links in Ethernet networks; here
too, redundancy leads to loops, but these can be broken by the use of
the Spanning Tree Protocol (STP). This technique can also be applied
in the case of multi-homed CEs in a VPLS domain. One approach is to
run STP on the multi-homed CE (say CE1 in Figure 1). CE1 would thus
detect a potential loop in the virtual LAN, and "block" either the
link to PE1 or to PE2, breaking the loop. Blocking the link to PE2
would effectively pick PE1 to be the designated forwarder, since (a)
PE2 will not get any traffic from CE1 to forward; (b) PE2's traffic
to CE1 will be ignored.
There are several operational disadvantages to the STP approach:
1. The SP has to trust the customer to run STP correctly and manage
changes carefully. If the customer makes a mistake, the SP will
pay for it by carrying the customer's "broadcast storm" across
the SP network.
2. The choice of whether PE1 or PE2 will be the "designated
forwarder" is made by the customer; however, the SP may feel that
they should make this choice, and in fact may be in a better
position to do so, as they know their network topology better.
3. STP has several characteristics that make it unsuitable for
carrier networks.
Another approach is to run STP on the PEs. However, the whole point
Kompella, et al. Expires May 15, 2008 [Page 5]
Internet-Draft BGP VPLS Multi-homing November 2007
of having a full mesh of PE-PE connections, and of "split horizon"
forwarding (Section 4.2.5 [2]; Section 4.4 [6]) is so that STP is not
needed on PEs. Furthermore, in Figure 2, PE1 must not block the
pseudowires to PE3 and PE4 in order to break the loop.
2.4. Active/Backup Links
Another approach is to define "active" and "backup" links from a
multi-homed CE to the PEs. For example, in Figure 1, CE1 could
define the link to PE1 as active and the link to PE2 as backup. If
the link to PE1, or PE1 itself, fails, the CE1 could detect this and
switch to the backup. However, again, the SP has to trust the
customer's staff to handle this correctly; also, the choice of
whether to use PE1 or PE2 remains with the customer.
2.5. Comparisons
One of the above methods may be acceptable in some cases. The
technique described in this memo is for those who are unsatisfied
with these methods. This technique relies on BGP mechanisms;
furthermore, the choice of "designated forwarder" is retained by the
SP. Finally, this technique can be used in conjunction with STP to
get further "insurance" against the possibility of loops.
Kompella, et al. Expires May 15, 2008 [Page 6]
Internet-Draft BGP VPLS Multi-homing November 2007
3. Procedures
BGP-based multi-homing for VPLS relies on two things: BGP path
selection and VPLS path selection. In this, it resembles BGP multi-
homing for IP VPNs. BGP path selection can be done by any BGP
speaker; a full understanding or parsing BGP VPLS advertisements is
not required. A good example is a Route Reflector [5], which
typically only has to do BGP path selection. A VPLS PE (i.e., a VE)
MUST do both BGP and VPLS path selection. The net result of doing
both BGP and VPLS path selection is that of electing a single
Designated Forwarder among the set of VEs to which a customer site is
multi-homed.
In order to explain how these two path selection algorithms work, one
must refer to the format of the VPLS NLRI. This NLRI contains:
<Route Distinguisher, VE ID, VE Block Offset, VE Block Size, Label
Base> (Section 3.2.2 [2]). We'll refer to these components as RD,
VE-ID, VBO, VBS and LB, respectively. In addition, a VPLS
advertisement contains some attributes, among them the BGP nexthop
(BNH), control flags (CF) and Local Preference (LP). Finally, the
VPLS domain (DOM) is needed; this is not carried explicitly in a VPLS
advertisement, but is derived, typically from BGP policies applied on
Route Targets carried in the advertisement. Taken all together, this
yields:
<RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, LP>
Note that an advertisement with VE-ID = 0 is invalid.
The path selection algorithms are described in two stages. The first
stage divides all received VPLS advertisements into buckets of
relevant and comparable advertisements. In this stage,
advertisements may be discarded as not being relevant to path
selection. The second stage picks a single "winner" from each bucket
by repeatedly applying a tie-breaking algorithm on a pair of
advertisements from that bucket. The tie-breaking rules are such
that the order in which advertisements are picked from the bucket
does not affect the final result. Note that this is a conceptual
description of the process; an implementation MAY choose to realize
this differently as long as the semantics are preserved.
3.1. BGP Path Selection
3.1.1. Bucketization
An advertisement
AD = <RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, LP>
Kompella, et al. Expires May 15, 2008 [Page 7]
Internet-Draft BGP VPLS Multi-homing November 2007
is discarded if DOM is not of interest to the PE. Otherwise, AD is
put into the bucket for <DOM, RD, VE-ID, VBO>. In other words, the
prefix to use for comparison in BGP path selection consists of <RD,
VE-ID, VBO>.
3.1.2. Tie-breaking Rules
Given two advertisements AD1 and AD2 as below, the following tie-
breaking rules MUST be applied in the given order (note that the RDs,
VE-IDs and VBOs are the same):
AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, BNH1, CF1, LP1>
AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, BNH2, CF2, LP2>
1. if (LP1 > LP2) AD1 wins; stop;
else if (LP2 > LP1) AD2 wins; stop;
else continue
2. if (BNH1 < BNH2) AD1 wins; stop;
else if (BNH2 < BNH1) AD2 wins; stop;
else AD1 wins; stop
3.2. VPLS Path Selection
3.2.1. Bucketization
An advertisement
AD = <RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, LP>
is kept only if DOM is of interest to the PE, and the following is
satisfied:
VBO <= N < (VBO + VBS - 1)
where N is one of the PE's VE IDs for VPLS DOM. If so, AD is put
into the bucket for <DOM, N>. Otherwise, AD is discarded.
3.2.2. Tie-breaking Rules
Given two advertisements AD1 and AD2 as below, the following tie-
breaking rules MUST be applied in the given order (note that the RDs,
VE-IDs and VBOs are the same):
AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, BNH1, CF:D1, LP1>
AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, BNH2, CF:D2, LP2>
where CF:D is the 'D' bit in the control flags (see
Kompella, et al. Expires May 15, 2008 [Page 8]
Internet-Draft BGP VPLS Multi-homing November 2007
[draft-kothari-l2vpn-auto-site-id]).
AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, BNH1, CF:D1, LP1>
AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, BNH2, CF:D2, LP2>
1. if (CF:D1 = 1) AD2 wins; stop;
else if (CF:D2 = 1) AD1 wins; stop;
else continue
2. if (LP1 > LP2) AD1 wins; stop;
else if (LP2 > LP1) AD2 wins; stop;
else continue
3. if (BNH1 < BNH2) AD1 wins; stop;
else if (BNH2 < BNH1) AD2 wins; stop;
else AD1 wins; stop
If the final "winning" advertisement has CF:D = 1 or VE-ID = 0 or VBO
= 0 or VBS = 0, it is discarded.
Kompella, et al. Expires May 15, 2008 [Page 9]
Internet-Draft BGP VPLS Multi-homing November 2007
4. Security Considerations
Having security is a Good Thing.
Kompella, et al. Expires May 15, 2008 [Page 10]
Internet-Draft BGP VPLS Multi-homing November 2007
5. Acknowledgments
The authors would like to thank Chaitanya Kodeboyina, Yakov Rekhter,
Nischal Sheth and Amit Shukla for their insightful comments and
probing questions.
Kompella, et al. Expires May 15, 2008 [Page 11]
Internet-Draft BGP VPLS Multi-homing November 2007
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling", RFC 4761,
January 2007.
6.2. Informative References
[3] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[4] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[5] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
April 2006.
[6] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
Kompella, et al. Expires May 15, 2008 [Page 12]
Internet-Draft BGP VPLS Multi-homing November 2007
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Bhupesh Kothari
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: bhupesh@juniper.net
Tom Spencer
at&t
Email: tsiv@att.com
Kompella, et al. Expires May 15, 2008 [Page 13]
Internet-Draft BGP VPLS Multi-homing November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kompella, et al. Expires May 15, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-21 03:36:35 |