Internet DRAFT - draft-sheng-ppvpn-isis-bgp-mpls
draft-sheng-ppvpn-isis-bgp-mpls
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
