Network Working Group Sheng Cheng INTERNET DRAFT Liu Yu Expiration Date: October 2003 Li Defeng Huawei Technologies. Chen Yunqing China Telecommunication April 2003 ISIS as the PE/CE Protocol in BGP/MPLS VPNs draft-sheng-isis-bgp-mpls-vpn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. Cheng Sheng Expires October 2003 [Page 1] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 Table of Contents 1 Terms ................................................. 2 2 Introduction .......................................... 2 3 Fundamental Requirments .............................. 3 3.1 Assumptions ........................................... 3 3.2 Multiple instances ................................... 3 3.3 IS-IS interaction with BGP on PE ..................... 3 3.4 Supplement............................................. 3 4 Extended Requirments .................................. 4 4.1 Sham Links ........................................... 4 4.2 Carry IS-IS imformation with BGP Extended communities . 4 4.3 Route loop prevention on PEs ......................... 5 4.4 IS-IS interaction with BGP on PE ..................... 5 4.5 Sham-link Creation ................................... 6 5 Acknowledgments ...................................... 7 6 References ........................................... 7 7 Authors' Address ..................................... 7 1. Terms 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. 2. Introduction The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [IS-IS]. [VPN] describes a VPN service architecture, in which BGP is used to distribute IP-VPN routes between PEs in IP backbone. A CE router can then learn the routes to other CE sites in the same VPN by peering with its attached PE router through a routing protocol. The routing protocol is in charge of exchanging routes between PE and its attached CE. It has been proved till now that BGP, OSPF or RIP can help. And of course, IS-IS can do it as well. Obviously, as one of the most widely used IGPs, IS-IS is capable of distributing routes of CE to PE router. Using IS-IS on the PE-CE link is prefered especially when the VPN use IS-IS as its intra-site routing protocol, which means less administative expense and good backward compatibility. This draft is mainly focusing on proposing two different solutions, in which one is fundamental and the other is somewhat complicated, to implement IS-IS between PE and its attached CE. Cheng Sheng Expires October 2003 [Page 2] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 3. Fundamental Requirments In this part, some basic requirements have been listed out to address the issues of IS-IS working on PE-CE link. 3.1 Assumptions +-----+ +-----+ | PE1 |---------| PE2 | +-----+ +-----+ | | | | +-----+ +-----+ | CE1 | | CE2 | +-----+ +-----+ Two different sites of one VPN are not connected by direct(backdoor) link. Further, if this physical link dose exist, there is no IS-IS adjacency over the backdoor link. If this can not be avoided, the second solution described in 4 should be choosed. 3.2 Multiple instances Multiple IS-IS instances should be supported on PE, which means multiple IS-IS instances can run in one PE with each bound to one specific VRF. The relationship between IS-IS instances and VRFs is listed as follows: Multiple IS-IS instances can be associated with the same VRF (n:1). A single IS-IS instance should not be associated with multiple VRFs (1:n). Of course, a single IS-IS instance can be associated with just a single VRF. 3.3 IS-IS interaction with BGP on PE The PE router should have the capability to import IS-IS and BGP routes to/from a particular VRF with each other. When importing the BGP routes into a single IS-IS instance bound to a specific VRF on PE, the routes will always be regarded as external routes and IS-IS deliver the route with external reachability TLV(TLV 130) in IS-IS LSP. The level of the converted IS-IS LSP is decided through configuration. 3.4 supplement - There is no special toplogy limitation for PE/CE link and CE's sites. - There is no special requirement for CE router. Cheng Sheng Expires October 2003 [Page 3] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4. Extended Requirments +-----+ +-----+ L1/2| PE1 |---------| PE2 |L1/2 +-----+ +-----+ | | | | +-----+ +-----+ | CE1 |-------- | CE2 | +-----+ +-----+ Though clear and easily implemented, the solution as per 3 has some disvantages, such as: - Routes delivered from one site to another are always treated as external routes is not desirable, because it will make the "false" routes undistinguished from the "real" external routes. - When there exists backdoor link connecting two CEs which belong to two different sites of one VPN, the IS-IS intra-area routes will be prefered to the VPN-IP routes which has been regarded as IS-IS external routes. As a result, the traffic will choose the direct link between CEs instead of passing through the IP backbone, which may be not accepted. - Besides, when backdoor exists between PEs, the route loop will happen on PEs, as both PE1 and PE1 import BGP routes into IS-IS. 4.1 Assumption There exists direct (backdoor) link between two different VPN sites. Further, there is IS-IS adjacency established over the backdoor link. 4.2 Carry IS-IS imformation with BGP Extended communities Per [VPN], BGP is in charge of distributing VPN-IP routes accross the VPN backbone. It is very useful of carrying some of the important original IS-IS route information by BGP with BGP extended communities. These "important" original IS-IS route information are listed as follows: -- IS-IS Route Type Extended Communites Attribute. This attribute is required, which is enconded with a two-byte type field and the type is 0201. The third byte is encoded as follows: -- Level type: The first bit. When it is set 0, it indicates level-1 type route and the value of 1 indicates level-2 type route. Cheng Sheng Expires October 2003 [Page 4] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 -- TLV Reachability type: The second bit. When it is set 0, it indicates that the original IS-IS route is of internal reachability and the value 1 indicates external reachability . -- Metric type: The third bit. When it is set 0, it indicates the original route is of internal metric type and the value of 1 indicates external metric type. -- sham-link endpoint address: the fourth bit. When it is set 1 , it indicates the route is of sham-link endpoint address, which will be specified in 4.5. By default, this bit should be set as 0. -- IS-IS System Id Extended Communites Attribute This attribute specifies the system id of the particular VRF from which this route was exported. It is encoded with a two-byte type and the type is 0202. The system id is carried in the rest six bytes. This attribute is optional, which means it is only necessary to be carried in the sham-link endpoint address route. 4.3 Route loop prevention on PEs As per the diagram of 4, when PE1 and PE2 both import bgp routes into their attached CE sites, the route loop will happen on both PEs. To avoid the route loop, it is assumed here that both PE1 and PE2 act as L1/2 router and there exists level-1 adjacency between each PE-CE link. The mechanism of how to avoid route loop with up/down bit in IS-IS level-1 LSP is specified in [ROUTE-LEAKING]. 4.4 IS-IS interaction with BGP on PE When PE receives a VPN-IP route, it will convert the route back to IS-IS. The creation of IS-IS LSP will be based on IS-IS route original information carried by BGP extended communities(as per 4.2). For example, if the orignal IS-IS route is of level-1 type /internal reachability/internal metric type, the route will be re-converted to a level-1 intra-area route with internal metric type. Besides, the configuration for route redistribution about the IS-IS LSP information is prefered. Cheng Sheng Expires October 2003 [Page 5] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4.5 Sham-link Creation As per [OSPF-VPN], sham-link plays a very important role for an link state IGP such as IS-IS and OSPF in preventing the VPN traffic going through backdoor between CEs. Before establishing the sham-link, each end PE should be assigned an real shamlink endpoint address which can be a loopback address in VRF to which the CE belongs. Also, we should ensure that the endpoint address of one side PE is visible to the PE of the other side. The source and destination sham-link endpoint address is desigated by configuraiton. For example, as per the diagram in 4, it is necessary to establish a sham-link between PE1 and PE2. As the first step for PE1, BGP imports the loopback direct route which is desigated as source shamlink endpoint address on PE2. Next, the converted BGP route carries BGP extended communities with sham-link endpoint address bit(as per 4.2) set and IS-IS System Id Extended Communites Attribute with the value be equal to the System id of the specific IS-IS instance on the PE2. When PE1 receives the route, it checks the sham-link endpoint address bit and gets the IS-IS System Id the BGP route carry. If the endpoint address PE1 get is similar to its configured destination sham-link endpoint address, it is believed that there exists an sham-link from PE1 to PE2. Finally, PE1 adds one Neighbor reachability TLV(TLV 2) in its self-originated LSP and floods it out to CE1. Similiar process will happend on PE2. Note: when the PE found the system id of the other end of the sham-link changed, it will flush the old LSP and generate new LSP according to the new system id get from BGP route. 5. Acknowledgments The authors would like to thank yangang, heqian, xuxiaofei, weixiugang chenjie for their comments on this work. Cheng Sheng Expires October 2003 [Page 6] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 6. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)". [Also republished as RFC 1142.] [IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [BGP-EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- communities-05.txt>, Sangli, S., Tappan, D., Rekhter, Y., May 2002 [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-02.txt, Rosen, E., et. al., July, 2002 [ROUTE-LEAKING] "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, T. Li Request, October 2000 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-rosen-vpns-ospf-bgp-mpls-06.txt, Eric C. Rosen, April 2003 7. Author's Addresses: Sheng Cheng D401 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : shengc@huawei.com Liu Yu A401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : liu_yu@huawei.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Chen Yunqing Email : chenyunqing@vip.sina.com Cheng Sheng Expires October 2003 [Page 7] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003