One document matched: draft-hlmu-l2vpn-bgp-discovery-00.txt
L2VPN Working Group Paul Unbehagen
Internet Draft Vasile Radoaca
Document: draft-hlmu-l2vpn-bgp-discovery-00.txt Praveen Muley
Nortel Networks
Sue Hares
Next Hop
Wei Luo
Cisco Sytems
Expires: August 20024 February 2004
BGP-based Auto-Discovery for L2VPNs
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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
Abstract
This document defines a mechanism of using BGP for the discovery of
L2VPN membership information. The L2VPN membership information can be
used by a L2VPN signaling protocol to set up pseudowires for L2VPNs,
such as VPWS and VPLS.
hlmu Expires - August 2004 [Page 1]
BGP Auto-Discovery for L2VPNs February 2004
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 [ii].
Table of Contents
1. Introduction...................................................2
2. Auto-Discovery Overview........................................2
3. BGP Protocol Details...........................................4
3.1 Overview...................................................4
3.2 AFI/SAFI encoding..........................................5
3.3 NLRI Encodings.............................................5
3.4 Use of RD format for AGI...................................5
3.5 Capabilities Negotiation for L2VPN Auto-Discovery..........6
3.6 Use of RT for Auto-Discovery...............................6
3.7 Use of RT for Controlling Traffic..........................6
4. Inter-AS Auto-Discovery........................................7
4.1 Proxy Mode.................................................7
4.2 Transparent Mode...........................................8
5. Security Considerations........................................9
6. Deployment Issues..............................................9
6.1 RD Value Selection.........................................9
6.2 Dynamic Signaling Session Creation........................10
References.......................................................11
Acknowledgments..................................................12
Author's Addresses...............................................12
1. Introduction
L2VPN signaling protocols described in [L2VPN-SIG] specify the
signaling procedures to set up various L2VPN models as defined in
[L2VPN-FRAME]. This document describes how BGP can be used to provide
an auto-discovery mechanism for L2VPN membership information that can
be used for the signaling procedures. The L2VPN membership consists
of identifiers of the Forwarders, the network address of the PE where
the Forwarders are provisioned, the VPN Identifier that the
Forwarders belong to, and other necessary information. This
information is encoded and distributed to other PEs through BGP
update messages.
2. Auto-Discovery Overview
[BGP-AUTO] describes the general framework of using BGP for auto-
discovery of both L2VPNs and L3VPNs, which is done through the
process of distributing a database of VPN membership on per PE basis.
The auto-discovery mechanism specified in this document is built on
hlmu Expires - August 2004 [Page 2]
BGP Auto-Discovery for L2VPNs February 2004
such a framework, and the VPN membership information obtained through
this mechanism can be used by L2VPN signaling protocols, such as LDP
or L2TP. It is assumed that the PEs that participate in the auto-
discovery process have the capability of using BGP peerings
supporting MPBGP and open capability negotiations. This document
builds on the foundation of Routing Distinguisher utilized in L3VPN
support of [2547bis].
The following diagram shows an example of an L2VPN that uses BGP
auto-discovery. Each PE can communicate with one another through BGP
sessions that are established either directly between PEs or by the
way of route reflectors. The BGP sessions are used to advertise L2VPN
membership information among the PEs. Once PEs learn such
information, they can establish L2VPN signaling connections and
pseudowires accordingly.
PE-1 PE-2
+-------------+ +--------------+
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-A | | | | | | | | | | VPN-A |
| Site1 |--| |Forwarder| | BGP VPN | |Forwarder | |-| site2 |
+--------+ | | A | |<----------->| | A | | +--------+
| +---------+ | Discovery | +----------+ |
| | | |
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-B | | | | | +---------+ | | | | | VPN-B |
| Site1 |--| |Forwarder| |-|Backbones|-| |Forwarder | |-| site2 |
+--------+ | | B | | +---------+ | | B | | +--------+
| +---------+ | | +----------+ |
| | | |
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-C | | | | | Signaling | | | | | VPN-C |
| Site1 |--| |Forwarder| |<----------->| |Forwarder | |-| site2 |
+--------+ | | C | | Protocol | | C | | +--------+
| +---------+ | | +----------+ |
+-------------+ +--------------+
[L2VPN-SIG] defines that each Forwarder is represented by a Forwarder
Identifier which is the concatenation of an Attachment Group
Identifier (AGI) and an Attachment Individual Identifier (AII).
To advertise a Forwarder, the AGI and AII are encoded in BGP MP-NLRI
fields and distributed to PEs participating in L2VPN auto-discovery.
All Forwarders belonging to the same L2VPN will have the same AGI.
When a PE receives a Forwarder advertisement through BGP, it uses the
AII encoded in the advertisement as the Target AII (TAII) for the
L2VPN signaling protocol. The Source AII (SAII) of the local
Forwarder is known through local configuration on the PE. When a
hlmu Expires - August 2004 [Page 3]
BGP Auto-Discovery for L2VPNs February 2004
Forwarder previously advertised is removed from a PE, the PE needs to
withdraw the AGI and AII of this Forwarder.
3. BGP Protocol Details
3.1 Overview
The BGP auto-discovery specified in this document is similar to the
schemes described [BGPVPN] and [LDPVPN], but further optimized. This
introduction provides the background on these mechanisms.
The L2VPN mechanisms have been designed to support both VPWS and VPLS
(normal and GVPLS). The mechanisms have been optimized to support the
rapid growth of either VPWS or VPLS usage.
The BGP multi-protocol attribute has the following fields [MPBGP]:
[AFI] [SAFI] [length of next hop] [next hop address] [number of
SNPAs] [length of SNPA1] [SNPA1][length of SNPA2] [SNPA2] ...
[length of SNPAn] [SNPAn]
BGP auto-discovery makes use of the coloring of routes in BGP and the
attachment of next hop addresses to a particular sub-network point of
attachment (SNPA) in the multi-protocol attribute.
The coloring of routes passed in the BGP protocol can be done by
associating either a BGP Community (normal [BGPCOMM] or extended
[BGPEXTCOMM]), and or extended information in the multi-protocol
Network Layer Reachability Information (NLRI). In L3VPNs [2547bis],
the coloring is done via a:
- Route Target as an Extended Community attribute, and
- an AFI/SAFI pair that allows the NLRI to be encoded as
12 bytes with 8 byte Route Distinguisher and a 4 byte IP v4
address.
The encoding of the AFI/SAFI alerts the L3VPNs that this AFI/SAFI
pair is used for L3VPNs.
As the deployment of the L3VPNs has increased, the fate sharing of
multiple BGP VPNs over a single TCP connection has caused problems in
some BGP deployments. In response to these problems, new BGP work
items are being proposed [IETF57, IDR notes] for reducing the fate
sharing of the VPNs. These proposed BGP mechanisms include: restarts
limited to a AFI-SAFI pair [nalawade-soft-notify], route-refresh
limited to a AFI-SAFI pair [BGPREFRESH], bundling of AFI/SAFIs over a
TCP connection [BGP-BUNDLE-TCP]. While proposed BGP mechanisms are
under consideration of the IDR group and have some deployment, these
items have not been approved as BGP drafts.
hlmu Expires - August 2004 [Page 4]
BGP Auto-Discovery for L2VPNs February 2004
These mechanisms can also reduce the fate-sharing of auto-discovery
mechanisms for different L2VPNS. If explosive growth occurs in
either the VPWS or VPLS deployments, utilizing these AFI/SAFI
isolation mechanisms may allow splitting of the processing of auto-
discovery mechanisms.
3.2 AFI/SAFI encoding
The AFI value will be XXXX (assigned by IANA) is used for all L2VPN
applications. The SAFI value will be set the following bit pattern:
0000 00LW -- where
L is the presence of VPLS
W is the presence of VPWS
Initial deployments are expected to have both VPLS and VPWS within an
L2VPN, and the SAFI value is set 3 to signify that the NRLI encoding
can be used for both VPLS and Future deployments that expect either
VPWS or VPLS but not both in an L2VPN may set the SAFI value in the
AFI/SAFI encoding to 1 for VPWS or 2 for VPLS.
3.3 NLRI Encodings
The encoding of the NRLI in the MP-BGP attribute is based on the
AFI/SAFI identifiers. For L2VPNs, the SAFI values of 1-3 will have
the following NLRI encoding:
Length of NLRI in bits, NLRI field (variable length)
Where the NLRI field is further defined as:
Length of AGI (in bits), AGI (variable),
Length of AII (in bits), AII (variable)
3.4 Use of RD format for AGI
The AGI is defined by [L2VPN-SIG]. For initial deployments, the AGI
may utilize the Route Distinguisher as defined by RFC 2547. This
section describes the appropriate use of the values of the Route
Distinguisher for the AGI. This text is non-normative, that is it
provides suggestions for deployment, but does not constitute any
requirements on the specification.
The RD is encoded as follows:
[type (2 octets)] [value (6 octets)]
hlmu Expires - August 2004 [Page 5]
BGP Auto-Discovery for L2VPNs February 2004
For deployment details on the RD, please refer to the section 6 on
deployment.
3.5 Capabilities Negotiation for L2VPN Auto-Discovery
In order for two BGP speakers to exchange L2VPN NLRI, they MUST use
negotiation scheme defined in [MPBGP-RFC 2842] to ensure both of them
capable of processing such NLRI correctly. Two BGP speakers
exchanging L2VPN NLRI service MAY use the dynamic capabilities
negotiation scheme defined utilizing the new capabilities message
[BGP-DYNCAP].
With either negotiation, the peer will specify the Multi-protocol
Extensions (capability 1) including in the capability list the
AFI/SAFI pairs for L2VPNs. As example, a BGP peer could announce in
the capability could specific AFI(XXX)/SAFI(1), AFI(XXX)/SAFI(2),
AFI/SAFI(3).
3.6 Use of RT for Auto-Discovery
If a Layer 2 Forwarder wishes to be discovered via BGP, it needs to
be provisioned with a Forwarder Identifier that consists of an AGI
and an AII and associate the Forwarder Identifier with one or more
Route Targets (RT) Extended Community attributes. The RT Extended
Community attributes are passed along with the BGP route.
3.7 Use of RT for Controlling Traffic
The RTs are utilized in BGP to control NLRI distribution. Each BGP
speaker can define a set of distribution policies using Route Targets
to control how addresses are advertised or accepted, thereby
governing the formation of the L2VPN network topology.
To form a full mesh, each Forwarder is configured with the same RT
value for both the "export RT" and the "import RT". This
distribution policy allows the Forwarders to be visible to all BGP
speakers having the same Route Target (Extended Community value).
After the all BGP peers have the Layer-2 information, they can set up
a full mesh of pseudowires among these Forwarders using the L2VPN
signaling procedures. (Note: Other BGP policy may not utilize Route
Targets and fully distribute the L2VPN information to all BGP
speakers within the full mesh.The key is the full distribution of
Layer-2 endpoints to the BGP speakers setting up the full mesh.)
Sometimes, a hub-and-spoke L2PVN network is desired. This can be
achieved by using two different RTs for distribution processing,
where one stands for "hub" and the other stands for "spoke". On the
hub PE, the "hub" RT is assigned to local Forwarders as the "export
RT", and the hub PE is configured to "import" only the L2VPN NLRIs
hlmu Expires - August 2004 [Page 6]
BGP Auto-Discovery for L2VPNs February 2004
that have the "spoke" RT. On the spoke PE, the "spoke" RT is assigned
to the local Forwarders as the "export RT", and the spoke PE is
configured to "import" only the L2VPN NLRIs that have the "hub" RT.
This distribution policy will result in (1) spoke PEs only seeing the
Forwarders configured on the hub PE, and (2) a hub PE seeing all
Forwarders configured on every spoke PE. The L2PVN signaling then
sets up pseudo-wires that form the hub-and-spoke topology.
A more complex topology is partial mesh. It can be done by using
sets of "import RTs" and "export RTs" to control route distributions.
4. Inter-AS Auto-Discovery
When PEs participating in L2VPNs reside in more than one AS, the BGP
auto-discovery procedures need to ensure that VPN membership
information can be communicated across AS boundaries. Depending on
how Forwarders on the PEs are connected in Inter-AS L2VPNs, ABSRs
operate in different modes which follow different procedures for
L2VPN auto-discovery [L2VPN-SIG].
PE-1 ----+ +---- PE-3
| |
| |
ASBR-1 ------- ASBR-2
| |
| |
PE-2 ----+ +---- PE-4
|<-- AS1 -->| |<-- AS2 -->|
4.1 Proxy Mode
Some network operators want to enforce certain policies including
those of L2VPNs at the AS boundaries, and they want L2VPN signaling
connections and pseudowires to be confined within an AS. In this mode
of operation, an ASBR acts as a ‘‘Proxy’’ PE that establishes and
manages signaling connections and pseudowires to the PEs in its own
AS on behalf of the PEs in another AS.
To connect two Forwarders on PE-1 and PE-3 respectively for instance,
three pseudowires need to be established and spliced together: one
from PE-1 to ASBR-1, one from ASBR-1 to ASBR-2, and one from ASBR-2
to PE-3.
Prior to establishing the pseudowires, PE-1 announces its Forwarder
information through a BGP update message. When receiving the BGP
update, ASBR-1 replaces the next-hop address with its own address so
that the recipient of the update thinks that ASBR-1 is provisioned
hlmu Expires - August 2004 [Page 7]
BGP Auto-Discovery for L2VPNs February 2004
with the Forwarder being advertised. In order to keep track of the
originating PE, the BGP Identifier of PE-1 is recorded in the first
SNAP field. ASBR-1 then announces the update to ASBR-2 with:
- next-hop address of ASBR-1, and
- SNAP1 filled with PE-1 BGP Identifier.
When ASBR-2 receives the update from ASBR-1, it performs the same
procedures as ASBR-1, so it announces the update to all PEs in AS2
with:
- next-hop address of ASBR-2, and
- SNAP1 with PE1 BGP Identifier, and
- SNAP2 with ASBR-1 BGP Identifier.
From the perspective of PE-3, the remote Forwarder advertised through
the update message is provisioned on ASBR-2, so PE-3 needs to set up
a pseudowire to ASBR-2 in order to connect to the remote Forwarder.
4.2 Transparent Mode
In this mode, L2VPN signaling connections and pseudowires traverse
the AS boundaries and are directly established between the PEs on
which Forwarders are provisioned. That is, ASBRs treat pseudowires
transparently and do not keep any stateful information of
pseudowires.
This deployment would most often be deployed within an enterprise or
carrier where the AS boundaries group information but do not provide
a hard boundary to the L2VPNs.
The ASBRs that deal with the AS confederations that replaced an IBGP
mesh may be a candidate to utilize the transparent mode. It is key
for the deployment and management issues to understand that the ASBRs
that do not support L2VPN auto-discovery and are included in the
transparent mode:
- must pass the information transparently through the router
without modification.
- will not keep any information about the state of the pseudo-
wires.
The ASBR that transparently pass the information can either:
1) support the L2VPN AFI/SAFI but be configured not
to participate in the L2VPN signaling procedures, or
2) be configured to transitive MP-BGP attributes without
processing any MP-BGP attributes.
For example, When receiving BGP updates that contain L2VPN NLRIs from
PEs in AS1, ASBR-1 simply relays them to the neighboring ASBR-2 which
further relays them to PEs in AS2 without modification.
hlmu Expires - August 2004 [Page 8]
BGP Auto-Discovery for L2VPNs February 2004
Besides passing the NLRIs, the transparent ASBRs also need to provide
Inter-AS network reachability for the PEs so that they can establish
L2VPN signaling connections and pseudowires to each other.
Entities utilizing the transparent mode must be careful to consider
all BGP issues, L2VPN signaling and policy issues. L3VPN also
utilizes this transparent mode of operation [2547bis].
5. Security Considerations
For the BGP sessions used for L2VPN auto-discovery, TCP MD5
authentication can be utilized. The L2VPN signaling protocols may
also use its native authentication mechanisms for security. For
example, LDP has TCP MD5 authentication as well, and L2TP has a CHAP-
like authentication scheme.
6. Deployment Issues
The deployment of L2VPN BGP auto-discovery in Enterprises, ISPs and
carrier networks uses the mechanisms described in this document will
also need to make some deployments decisions. This section provides
some background on deployment issues gained from BGP and L3VPNs.
These deployment issues are:
1. regarding RD value selection,
2. auto-configuration mechanisms for BGP and Signaling protocol
setup.
This section is non-normative, that is it is not binding on an
implementation.
6.1 RD Value Selection
L2VPN auto-configurations are being deployed to ease the
configuration burden of L2VPNs over MPLS. In choosing an RD, it is
important to understand the issues between the three existing types
of RD values. For ease of transition between type 0-2 RD values, it
may be useful to restrict the assigned number to 2 bytes.
The following is the definition of the RD bytes from [BGP2547bis]:
[type (2 octets)]
[Value (6 octets)]
type 0: [Administrator (2 octets), Assigned number (4 octets)]
type 1: [Administrator (4 octets), Assigned number (2 octets)]
type 2: [Administrator (4 octets), Assigned number (2 octets)]
hlmu Expires - August 2004 [Page 9]
BGP Auto-Discovery for L2VPNs February 2004
A type 0 RD Administrator filed has two octets for an Administrator
value (2 bytes) that is drawn from the public autonomous system (AS)
number space combined with a 4 byte assigned number. Today, the AS
numbers fit within 2 bytes. Within 3-7 years, the AS numbers may
exceed the 2 byte space, and require the 4 byte AS numbers. It would
be wise to only use the 2 bytes of Assigned number for type 0 and
type 2 assigned numbers. Type 1 uses an assigned IP address [4
bytes] as the administrator identifier. This address in the type 1
RD administrator field should utilize.
The type 1 RD administrator field an IP address is from the public IP
address space. Private address numbers used for administrator
numbers should not be used in RDs. Use of private address numbers
(such as network 10) may run into collisions with two network
deployments using the same IP address.
6.2 Dynamic Signaling Session Creation
The purpose of BGP auto-configuration is to reduce the configuration
burden for setup of psuedowires. In deployment of the BGP auto-
discovery just as in the normal BGP, the policy controlling the auto-
configuration uses configuration plus the existence of the
information in BGP as the impetus to establish a signaling session.
Signaling sessions MAY be established before or after the BGP auto-
discovery phase is completed. This can be done in two ways:
1. Each PE can have a signaling session manually created to all the
PEs participating in L2VPN in the network before the BGP auto-
discovery, regardless of whether they have any forwarders in
common or not OR
2. Each PE can set up a session to other PEs dynamically as the BGP
auto-discovery phase progresses if they have at least one
forwarder in common after the auto-discovery phase is complete.
Approach (1) has the benefit of simplicity and pre-determined
behavior in that the L2VPN signaling sessions may not go up and down
depending on dynamic L2VPN memberships.
Approach (2) provides complete automatic creation of signaling
sessions based on the BGP auto-discovery mechanisms and local policy.
The benefit of this approach is that reduces the configuration burden
to a minimum. Once obtain L2VPN membership information through BGP
auto-discovery, a PE may start L2VPN signaling sessions to other PEs.
With either approach, whenever a new Forwarder is added to an L2VPN,
a PE MUST advertise its information to all other PEs through BGP. The
receiving PE may initiate a pseudowire to the advertising PE with the
information learnt through BGP auto-discovery. Whenever an existing
Forwarder is removed from an L2VPN, a PE MUST withdraw the previous
hlmu Expires - August 2004 [Page 10]
BGP Auto-Discovery for L2VPNs February 2004
advertisement of this Forwarder through BGP. PEs with pseudowires
connecting to this Forwarder will also receive an update through the
signaling sessions notifying that the Forwarder is removed.
Either approach may be chosen for deployment depending on given
deployment requirements.
References
[2547bis] ‘‘BGP/MPLS VPN’’, Rosen, et. al., draft-ietf-l3vpn-
rfc2547bis-01.txt, September 2003.
[BGP-AUTO] ‘‘Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto-
03.txt, August 2002.
[BGP-BUNDLE-TCP], "Multisession BGP", John G. Scudder, Chandra
Appanna, November 2003,
draft-scudder-bgp-multisession-00.txt
[BGPCOMM], " BGP Communities Attribute", R. Chandra, P. P. Traina, T.
Li, RFC 1997, August 1996
[BGP-DYNCAP], "Dynamic Capability for BGP-4", Enke Chen, Srihari R.
Sangli, draft-ietf-idr-dynamic-cap-04.txt
[BGPEXTCOMM], "BGP Extended Communities Attribute",Srihari R. Sangli,
Daniel Tappan, Yakov Rekhter, draft-ietf-idr-bgp-ext-
communities-06.txt, August 2003
[BGPREFRESH], "Route Refresh Capability for BGP-4", Chen E.,RFC 2918,
September 2000.
[BGPVPN] "Using BGP as an Auto-Discovery Mechanism for Network-based
VPNs", H. Ould-Brahim et. al., draft-ietf-ppvpn-bgpvpn-
auto-03.txt, August 2002
[L2VPN-FRAME] ‘‘L2VPN Framework’’, Anderson, et. al., draft-ietf-l2vpn-
l2-framework-03.txt, October 2003.
[L2VPN-SIG] ‘‘Provisioning Models and Endpoint Identifiers in L2VPN
Signaling’’, Rosen, Radoaca draft-ietf-l2vpn-signaling-
01.txt, Feb 2004.
[LDPVPN] Eric Rosen, "LDP-based Signaling for L2VPNs",draft-rosen-
ppvpn-l2-signaling-02.txt, September 2002
hlmu Expires - August 2004 [Page 11]
BGP Auto-Discovery for L2VPNs February 2004
[MPBGP-RFC 2842] "Multiprotocol Extensions for BGP-4", Bates, T., Y.
Rekhter, R. Chandra, D. Katz, RFC 2842, June 2000
[SOFT-NOTIFY] "BGPv4 Soft-Notification Message", Gargi Nalawade,
Keyur Patel, John Scudder, David Ward, October 2003.
[VPLS-LDP] ‘‘Virtual Private LAN Services over MPLS’’ draft-ietf-ppvpn-
vpls-ldp-01.txt V.Komeplla, Marc Lasserre, November 2003
[VPLS-BGP] ‘‘Virtual Private LAN Service’’, K. Kompella, Y. Rekhter,
draft-ietf-l2vpn-vpls-bgp-01.txt, January 2004
Acknowledgments
We wish to thank Hamid Ould-Brahim, Shobhan Lakkapragada, Florin
Balus (Nortel Networks) and Eric Rosen from Cisco for their comments and
contributions.
Author's Addresses
Susan Hares
Merit, Inc.
1071 Beal Avenue,
Ann Arbor,
MI 48109
Wei Luo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: luo@cisco.com
Paul Unbehagen
Nortel Networks
35 East Davis Dr.
RTP, NC 27709
Phone: 919-905-2956
Email: paulu@nortelnetworks.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: (781) 856-0590/978-288-6097
vasile@nortelnetworks.com
hlmu Expires - August 2004 [Page 12]
BGP Auto-Discovery for L2VPNs February 2004
Praveen Muley
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: 978-288-3603
Email : pmuley@nortelnetworks.com
hlmu Expires - August 2004 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 00:30:10 |