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]