Network Working Group Sina Mirtorabi Internet-Draft Force10 Networks Expires: October 2007 Peter Psenak Mukhtiar Shaikh Cisco Systems April 2007 Maintaining IGP transparency of VPN routes when BGP is used as a PE-CE protocol draft-mirtorabi-l3vpn-igp-transparency-00.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. This Internet-Draft will expire on July 24, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Mirtorabi, et al. IGP transparency with BGP [Page 1] Internet-Draft April 2007 Abstract Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). Although specification has been defined allowing OSPF or other IGP to be used as PE-CE routing protocol, BGP is often used as PE-CE routing protocol. Section 2 describes some of the motivations to use BGP as PE-CE routing protocol. The usage of BGP breaks customer route's transparency when they move from an overlay VPN model to MPLS VPN model. This document describes the extension to CE in order to keep the customer routes' transparent when BGP is used as PE-CE routing protocol. 1. Introduction [MPLS-VPN] defines the base specification for BGP/MPLS IP VPNs in which a customer edge router (CE) exchanges routing information with provider edge router (PE) through BGP [BGP]. The PE routers attached to a common VPN further exchange VPN's routes with each other through BGP. This allows service providers to use their backbone to provide VPN services to their customers. One of the main requirements for customers is to keep their routes transparent when they move from an overlay VPN model to MPLS VPN model. In order to keep transparency of IGP routes, extensions have been defined when IGP is used as PE-CE routing protocol, in particular, [L3VPN-OSPF] describes the extension to the base specification in order to run OSPF as PE-CE routing protocol. This allows the customer's OSPF routes to remain unchanged when they move to a MPLS VPN service but also solves the path preference via Sham Link (SL) in the presence of backdoors. [L3VPN-OSPF] or other IGP specifications allows keeping IGP transparency as long as the IGP is used as PE-CE routing protocol, however the most deployed and preferred PE-CE routing protocol is BGP. In such a scenario, the customer edge router (CE) has to redistribute the routes learned from PE trough BGP into IGP, therefore the remote routes will appear as external in customer sites. This not only breaks the transparency of IGP routes but also causes problems in the presence of backdoor link. Specifically when OSPF is used as IGP, internal OSPF routes are always preferred over external route therefore MPLS path through provider will not be used. This document presents a specification in order to keep OSPF routes transparent when BGP is used as a PE-CE Protocol. The discussion in the draft is focused on OSPF but similar approach can be extended for other IGPs when such a transparency may be desired. Mirtorabi, et al. IGP transparency with BGP [Page 2] Internet-Draft April 2007 2. Motivation for Service provider to use BGP In most deployment BGP is used as PE-CE routing protocol. The choice of routing protocol is normally agreed upon between service provider and customers. In many occurrence service provider advise customer to use BGP as PE-CE routing protocol. The motivation for service providers to use BGP could be as follow: o Better knowledge of the protocol Service Providers are familiar with BGP as this protocol is extensively used in their backbone for Internet and MPLS VPN connectivity. Some service providers may run ISIS and even not be familiar with OSPF. o Better scalability Service provider wish to maximize the usage of provider edge device (PE) by having PE device to support thousands of VRF and routing peers. BGP is known to be highly scalable and meet ideally that requirements. OSPF may not highly scale specially if the link state database size for each attached site is big. Further OSPF internal routes could not be summarized before being advertised to PE which is not the case when BGP is used as PE-CE routing protocol o Better PE protection As PE device is shared among many customers, there is a requirement to have some protection mechanism in order to limit the number of route learned from customers sites. This not only for policy agreement verification but also to protect PE resources should a high number of routes be advertised from CE to PE. Because of distance vector behavior of BGP, it is easy to limit the number of routes learned via CE. On the other hand when OSPF is used as PE-CE routing protocol, PE protection could become an issue because of link state behavior of OSPF. More specifically, number of routes could not be relied to protect PE. Some implementations have protection mechanism for OSPF however this is not globally available by all vendors and the method of protection could be implementation specific. 3. Motivation for customers to use BGP Usually (and in the absence of this specification) customer's interest is to use local IGP as PE-CE routing protocol, mainly Mirtorabi, et al. IGP transparency with BGP [Page 3] Internet-Draft April 2007 because customer routes' remains transparent when they move to MPLS VPN service; they don't have to break their backdoor or run BGP over the backdoor in order to solve path preference over MPLS cloud. There is however a motivation for customer to use BGP as PE-CE routing protocol, when the customer is connected to two service providers for MPLS VPN service redundancy and there is no Inter-AS VPN [MPLS-VPN] connectivity between the providers. In such a scenario the customer wants to provide backup connectivity through hub sites for sites that are single homed to different service providers (or sites dual homed which became single homed due to failure) however DN-bit prevent such a backup connectivity, as LSAs received from a service providers cannot be advertised through hub sites to another service provider. The use of BGP solves this problem and prevents any routing loop should the route be advertised back to the originator site. 4. Procedure for PE operations As PE device runs BGP to exchange routing information with CE, there is no change in PE operations and the specification is the same as defined in [MPLS-VPN]. 5. Procedure for CE operations This document extends the specification for BGP/OSPF interaction defined in [L3VPN-OSPF] to CE. In particular the mechanism described in section 4 of [L3VPN-OSPF] are extended to CE. In the following section we highlight the differences with [L3VPN-OSPF] in definitions or mode of operations when applicable. In order to keep the transparency between OSPF routes belonging to different sites, the CE needs to know the remote OSPF domain along with OSPF route type and OSPF metric. That information is encoded and attached by CE when OSPF is redistributed into BGP and advertised as BGP Extended Communities attribute [EXTCOMM]. The BGP extended communities defined in [L3VPN-OSPF] cannot be used as they are not transitive and will not be propagated through service provider AS. We propose to define the following new type BGP Extended communities: o The OSPF Domain Identifier Extended Communities attribute. This attribute is defined in [L3VPN-OSPF]. This attribute is encoded with a two-byte type field, and its type is either 0x4005 or 0x4105. o OSPF Route Type Extended Communities Attribute. This attribute is defined in [L3VPN-OSPF]. This attribute is encoded with a two-byte type field, and its type is 0x4306. Mirtorabi, et al. IGP transparency with BGP [Page 4] Internet-Draft April 2007 o OSPF Router ID Extended Communities Attribute. This attribute is defined in [L3VPN-OSPF]. This attribute is encoded with a two-byte type field, and its type is 0x4107. The following new BGP extended community is also defined in order to keep OSPF metric across service provider backbone, as MED can not be used to convey that information. o OSPF metric Extended Communities Attribute. This attribute MUST be present. It is encoded with a two-byte type field, and its type is 0x4108. The metric is encoded in the first 2 bytes (if it is an intra-area route) or 3 bytes (if it is an Inter-area route) of the value field. By default, this SHOULD be set to the the value of the OSPF cost associated with the route, plus 1. 6. CE functionality as ABR In order to generate Inter-area route to its attached areas based on BGP Extended communities, the CE device will act as an ABR as defined in [OSPF]. It is therefore required that the CE device connect to area 0 should area 0 exist within the site where CE resides. 7. Loop prevention DN-bit as defined in [OSPF-DN] is set in any LSA that is generated from CE to the site. This is done in order to prevent a potential routing loop where the prefix advertised by a CE could be received by another CE attached to the same site and sent back to the MPLS cloud. When a CE acting as defined in this document, receives any LSA with DN-bit set, the LSA should not be used for route calculation. 8. VPN route tag As DN-bit is set in any LSA advertised from CE to the site, there is no need to support VPN route tag as defined in [L3VPN-OSPF]. The support of VPN route tag is therefore OPTIONAL. In some cases it could be convenient to use tag for loop prevention where OSPF is redistributed into a third routing protocol and then back into OSPF. 9. OSPF-BGP route preference When a site is dual homed and both CEs advertise the site's prefix to PEs, each CE could receive the same route both through OSPF and EBGP. Normally both CEs resides in the same AS and the AS-Path will prevent the BGP route to be installed, therefore OSPF route gets installed and advertised to PE which is the desired behavior. Mirtorabi, et al. IGP transparency with BGP [Page 5] Internet-Draft April 2007 There are however situations where the AS-Path is either modified or the AS-PATH check is disabled by local policy for dual homed site or in some case where CEs are in different AS and there is a backdoor, the same route preference may be desired, i.e. OSPF route needs to be preferred over EBGP route. In order to achieve that, the preference of EBGP routes associated to PE are set by default higher than IGP routes preference. 10. Sham link Sham Link is defined in [L3VPN-OSPF] in order to solve, intra-area versus Inter-area path preference, where MPLS VPN route appears as Inter-area route and less preferred compared to backdoor intra-area path. In the context of this document, Sham Link is a multi-hop adjacency between two CEs and providing the same functionality as in [L3VPN-OSPF]. Namely creating an intra-area path between the CEs through MPLS cloud. The Sham link end point address are /32 IPv4 address and MUST be reachable through BGP. In particular the sham link end point address Must Not be advertised through OSPF. 11. Security Considerations The security consideration relevant to MPLS VPN where BGP is used as PE-CE routing protocol is discussed in [MPLS-VPN]. Therefore this document does not introduce any new security considerations. 12. IANA Considerations Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP Extended Communities Type Field and Extended Type Field values. Section 5 of this document assigns new values for the BGP Extended Communities Extended Type Field. These values fall within the range of values which [EXTCOMM] states "are to be assigned by IANA, using the 'First Come, First Served' policy defined in RFC 2434". The BGP Extended Communities Extended Type Field values assigned in section 5 of this document are: o OSPF Domain Identifier: Extended Cummunitiy Types 0x4005, 0x4105 o OSPF Route Type: Extended Cummunitiy Type 0x4306 o OSPF Router ID: Extended Cummunitiy Type 0x4107 o OSPF metric: Extended Cummunitiy Type 0x4108 Mirtorabi, et al. IGP transparency with BGP [Page 6] Internet-Draft April 2007 13. Authors' addresses Sina Mirtorabi Force10 Networks 350 Holger Way San Jose, CA 95134, USA E-mail: sina@cisco.com Peter Psenak Cisco Systems Mlynske Nivy 43 821 09 Bratislava Slovakia E-mail: ppsenak@cisco.com Mukhtiar Shaikh 255 West Tasman Drive San Jose, CA 95134 E-mail: mshaikh@cisco.com 14. References [MPLS-VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, E. Rosen and Y. Rekhter, February 2006 [L3VPN-OSPF] "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs", RFC 4577, Rosen, Psenak, Pillay-Esnault, June 2006 [EXTCOMM] "BGP Extended Communities Attribute", RFC 4360, Sangli, S., Tappan, D., Rekhter, Y., February 2006 [OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", draft-ietf-ospf-2547-dnbit-04.txt, Rosen, Psenak, Pillay- Esnault, March 2004 [BGP] "A Border Gateway Protocol 4 (BGP-4)", Rekhter, Y., Li, T., Hares, S., RFC 4271, January 2006 Mirtorabi, et al. IGP transparency with BGP [Page 7] Internet-Draft April 2007 15. Intellectual Property Rights Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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 implementors 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. 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. Mirtorabi, et al. IGP transparency with BGP [Page 8]