l1vpn WG Hamid Ould-Brahim Don Fedyk Internet Draft Nortel Expiration Date: May 2007 Yakov Rekhter Juniper Networks October 2006 BGP-based Auto-Discovery for L1VPNs draft-ietf-l1vpn-bgp-auto-discovery-01.txt 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. Abstract The purpose of this draft is to define a BGP-based auto- discovery mechanism for layer-1 VPNs. The auto-discovery mechanism for l1vpns allows the provider network devices to dynamically discover the set of PEs having ports attached to CEs member of the same VPN. That information is necessary for completing the signaling phase. One main objective of l1vpn auto-discovery mechanism is to support "single-end provisioning" model, where addition of a new port to a given l1vpn would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. Ould-Brahim, Fedyk, Rekhter October 2006 [Page 1] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 Changes to previous version: - Added section 4 on carrying TE attribute in BGP. - Added section 5 on scalability for using BGP as an auto- discovery mechanism for l1vpns. - Completed section 6 on Security Considerations. - Added section 7 on IANA considerations. 1. Introduction The purpose of this draft is to define a BGP-based auto- discovery mechanism for layer-1 VPNs. The auto-discovery mechanism for l1vpns allows the provider network devices to dynamically discover the set of PEs having ports attached to CEs member of the same VPN. That information is necessary for completing the signaling phase. One main objective of l1vpn auto-discovery mechanism is to support "single-end provisioning" model, where addition of a new port to a given l1vpn would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of tuples local to that PE. Once that information is received, the remote PEs will identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to perform address resolution during signaling phase. PE PE +---------+ +--------------+ +--------+ | +------+| | +----------+ | +--------+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | +--------+ | | ||<----------->| | | | +--------+ | +------+| Distribution| +----------+ | | | | | +--------+ | +------+| | +----------+ | +--------+ | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | | CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 | +--------+ | | || (Backbone ) | | | | +--------+ | +------+| --------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | | CE1 |--| |PIT | | | | PIT | |-| CE2 | +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+ Figure 1 BGP auto-discovery for l1vpn Ould-Brahim et al. October 2006 [Page 2] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 This version of the draft focuses on describing an auto- discovery mechanism for the basic mode only. Details for the enhanced mode will be described in future revised version of this draft. 2. Procedures In the context of l1vpns, a CE is connected to a PE via one or more ports, where each port may consists of one or more channels or sub-channels. Each port on a CE that connects the CE to a PE has an identifier that is unique within that l1vpn (but need not be unique across several l1vpn). We refer to this identifier as the customer port identifier (CPI). Each port on a PE has as well an identifier that is unique within that provider network. We refer to this identifier as the provider port identifier (PPI). Note that IP addresses used for CPIs, PPIs could be either IPv4 or IPv6 addresses. A PE maintains for each l1vpn configured on that PE a port information tables (PIT) associated with each l1vpn that has at least one port configured on a PE. A PIT contains a list of tuples for all the ports within its l1vpn. Note that a PIT may as well hold routing information (for example when CPIs are learnt using a routing protocol). A PIT on a given PE is populated from two sources: the information related to the CEs’ ports attached to the ports on that PE (this information could be optionally received from the CEs), and the information received from other PEs through the auto-discovery mechanism. We’ll refer to the former as the "local" information, and to the latter as the "remote" information. Propagation of local information to other PEs is accomplished by using BGP multiprotocol extensions as specified in [BGP-VPN- AUTODISCOVERY]. To restrict the flow of this information to only the PITs within a given l1vpn, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows. Each PIT on a PE is configured with one or more Route Target Communities, called "export Route Targets", that are used for tagging the local information when it is exported into provider’s BGP. The granularity of such tagging could be as fine as a single pair. In addition, each PIT on a PE is configured with one or more Route Target Communities, called "import Route Targets", that restrict the set of routes that could be imported from provider’s BGP into the PIT to only the routes that have at least of these Communities. Ould-Brahim et al. October 2006 [Page 3] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 When a service provider adds a new l1vpn port to a particular PE, this port is associated at provisioning time with a PIT on that PE, and this PIT is associated (again at provisioning time) with that l1vpn. Note that since the protocol used to populate a PIT with remote information is BGP, since BGP works across multiple routing domains, it follows that the mechanisms described in this document could support l1vpns that span multiple routing domains. 3. Carrying l1vpn information in BGP The mapping is carried using the Multiprotocol Extensions BGP [RFC2858]. [RFC2858] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be used to announce and withdraw the announcement of reachability information. We introduce a new a new subsequent address family identifier (to be assigned by the IANA), and also a new NLRI format for carrying the CPI and PPI information. One or more tuples could be carried in the above mentioned BGP attributes. The format of encoding a single tuple is shown in Figure 2 below: +---------------------------------------+ | Length (1 octet) | +---------------------------------------+ | PPI Length (1 octet) | +---------------------------------------+ | PPI (variable) | +---------------------------------------+ | CPI AFI (2 octets) | +---------------------------------------+ | CPI (length) | +---------------------------------------+ | CPI (variable) | +---------------------------------------+ Figure 2: NLRI BGP encoding The use and meaning of these fields are as follows: Length: A one octet field whose value indicates the length of the Information tuple in octets. PPI Length: A one octet field whose value indicates the length of Ould-Brahim et al. October 2006 [Page 4] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 of the PPI field PPI field: A variable length field that contains the value of the PPI (either an address or tuple CPI AFI field: A two octets field whose value indicates address family of the CPI. CPI Length: A once octet field whose value indicates the length of the CPI field. CPI (variable): A variable length field that contains the CPI value (either an address or tuple. If the value of the Length of the Next Hop field is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address. 4. Carrying L1VPN Traffic Engineering Information in BGP In addition to reachability information, the auto-discovery mechanism may carry Traffic Engineering information that will be used for signaling purposes. For example a PE may learn from the remote PEs, the switching capability, the maximum LSP bandwidth of the remote l1vpn interfaces. This document proposes the use of the BGP attribute defined in [BGP-TE-ATTRIBUTE] to carry such information. 5. Scalability Recall that the Service Provider network consists of (a) PE, (b) BGP Route Reflectors, (c) P nodes (which are neither PEs nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs. A PE router, unless it is a Route Reflector should not retain L1VPN-related information unless it has at least one VPN with an Import Target identical to one of the VPN-related information Route Target attributes. Inbound filtering should be used to cause such information to be discarded. If a new Import Target is later added to one of the PE's VPNs (a "VPN Join" operation), it must then acquire the VPN-related information it may previously have discarded. Ould-Brahim et al. October 2006 [Page 5] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 This can be done using the refresh mechanism described in [BGP- RFSH]. The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] can also be used to advantage to make the filtering more dynamic. Similarly, if a particular Import Target is no longer present in any of a PE's VPNs (as a result of one or more "VPN Prune" operations), the PE may discard all VPN-related information which, as a result, no longer have any of the PE's VPN's Import Targets as one of their Route Target Attributes. Note that VPN Join and Prune operations are non-disruptive, and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used. As a result of these distribution rules, no one PE ever needs to maintain all routes for all L1VPNs; this is an important scalability consideration. Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the L1VPNs supported by the Service Provider. Thus no single route reflector is required to maintain VPN-related information for all VPNs. For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs need not maintain and distribute VPN-related information at all. P routers do not maintain any VPN-related information. As a result, no single component within the Service Provider network has to maintain all the VPN-related information for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component. An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the case of the Internet, where the Internet BGP system must carry all the Internet routes. Thus one significant (but perhaps subtle) distinction between the use of BGP for the Internet routing and the use of BGP for distributing VPN-related information, as described in this document is that the former is not amenable to partition, while the latter is. 6. Security Considerations This document describes a BGP-based auto-discovery mechanism which enables a PE that attaches to a particular L1VPN to discover the set of other PE routers that attach to the same VPN. Each PE router that is attached to a given VPN uses BGP to advertise that fact. Other PE routers which attach to the same VPN receive these BGP advertisements. This allows that set Ould-Brahim et al. October 2006 [Page 6] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 of PE to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements may be received from "intermediate" BGP speakers. It is of critical importance that a particular PE should not be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE nodes, and if the PE nodes accepted those advertisements, then anyone could add any site to any L1VPN. Thus the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further that it can trusts those peers to be properly securing their local attachments. (That is, a PE must trust that its peers are attached to, and are authorized to be attached to, the L1VPNs to which they claim to be attached.). If a particular remote PE is a BGP peer of the local PE, then the BGP authentication procedures of RFC 2385 can be used to ensure that the remote PE is who it claims to be, i.e., that it is a PE that is trusted. If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE must trust that its peers only accept information from peers that they trust in turn, and this trust relation must be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence the procedures of this document should be used only in environments where adequate trust relationships exist among the BGP speakers. 7. IANA Considerations SAFI number to be assigned by IANA for carrying l1vpn information in the NLRI. 8. References [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt, work in progress [BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., Rekhter, Y., "Traffic Engineering Attribute", draft-fedyk-bgp-te-attribute-01.txt, work in progress. Ould-Brahim et al. October 2006 [Page 7] draft-ietf-l1vpn-bgp-auto-discovery-01.txt October 2006 [GVPN] Ould-Brahim, H., Rekhter, Y., et al., "Generalized VPNs using BGP and GMPLS toolkit", work in progress, August 2005. [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities- 08.txt, August 2005, work in progress. [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283. [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC 2918, October 2000. [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering Capability for BGP-4", draft-ietf-idr-route- filter-16.txt, Work in Progress. [BGP-CONS] Marques, P., et al., "Constrained VPN route distribution", draft-ietf-l3vpn-rt-constrain-02.txt, work in progress. [L1VPN-FRMK] Tomonori Takeda, et al., "Framework and Requirements for Layer 1 Virtual Private Networks", draft- ietf-l1vpn-framework-04.txt, October 2006, work in progress. 9. Author's Addresses Hamid Ould-Brahim Nortel P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortel.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: yakov@juniper.net Don Fedyk Nortel 600 Technology Park Billerica, Massachusetts 01821 U.S.A Phone: +1 (978) 288 3041 Email: dwfedyk@nortel.com Ould-Brahim et al. October 2006 [Page 8] draft-ietf-l1vpn-bgp-autodiscovery-01.txt October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of and 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Ould-Brahim et al. October 2006 [Page 9]