One document matched: draft-dong-idr-vpn-route-constrain-00.txt
Network working group J. Dong
Internet Draft M. Chen
Intended status: Standards Track G. Liu
Expires: April 19, 2010 H. Ni
Huawei Technologies Co., Ltd.
October 19, 2009
Constrained Route Distribution for BGP based Virtual Private Networks
(VPNs)
draft-dong-idr-vpn-route-constrain-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 15, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Dong, et al. Expires April 19, 2010 [Page 1]
Internet-Draft BGP Based VPN Route Constrain October 2009
Abstract
This document defines generalized procedures that allow BGP speakers
to exchange Route Target reachability information. This information
can be used to precisely control the propagation of different kinds
of Virtual Private Network (VPN) routing information. This method
avoids unnecessary advertising of VPN routes when more than one kind
of VPN is deployed in the network.
Table of Contents
1. Introduction.................................................2
1.1. Terminologies...........................................3
2. Conventions used in this document............................3
3. Multiple Kinds of VPNs in Service Provider Network...........3
3.1. Multiple VPNs with Different AFIs.......................4
3.1.1. IPv4 L3VPN and IPv6 L3VPN..........................4
3.1.2. L3VPN and L2VPN....................................5
3.2. Multiple VPNs with Different SAFIs......................6
4. Considerations about Route Constraint in IPv6 L3VPN..........8
5. Considerations about Route Constraint in L1VPN...............8
6. Proposed Solutions...........................................8
6.1. Length of Route Target Field............................8
6.2. Identifying RT Membership of Different VPNs.............8
6.2.1. Identifying AFI of VPNs............................8
6.2.2. Identifying SAFI of VPNs...........................9
6.2.3. Proposed Format of RT Membership NLRI..............9
7. Security Considerations.....................................10
8. IANA Considerations.........................................10
9. References..................................................10
9.1. Normative References...................................10
9.2. Informative References.................................11
Authors' Addresses.............................................12
1. Introduction
BGP [RFC4271] has been widely used in many kinds of Virtual Private
Networks (VPNs) for exchanging routes and auto discovery information.
Route Target (RT) extended communities defined in [RFC4360] are used
to control the distribution of received information into VRFs.
[RFC4684] defines some procedures to restrict the distribution of VPN
routes. It defines a new MP-BGP NLRI with [AFI=1, SAFI=132] for
carrying RT membership information, which can be used to control the
propagation of VPN routes. The procedures are helpful in limiting the
propagation of VPN routes in networks where only one kind of VPN is
Dong, et al. Expires April 19, 2010 [Page 2]
Internet-Draft BGP Based VPN Route Constrain October 2009
deployed. If multiple different kinds of VPNs are used in the network,
the procedures in RFC 4684 are not sufficient for providing precise
control of VPN route distribution.
This document analyses possible problems RFC 4684 may meet with and
also provides solutions for these problems.
1.1. Terminologies
Terms and acronyms specific to BGP and VPNs are listed below:
AFI Address Family Identifier
CE Customer Edge
L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
MVPN Multicast L3VPN
NLRI Network Layer Reachability Information
PE Provider Edge
RT Route Target
SAFI Subsequent Address Family Identifier
VPLS Virtual Private LAN Service
VPN Virtual Private Network
2. 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 [RFC2119].
3. Multiple Kinds of VPNs in Service Provider Network
In many scenarios, it is possible that Service Provider (SP) needs to
deploy more than one kind of VPNs in their network. For example, one
SP may deploy both IPv4 L3VPN and IPv6 L3VPN, or both L3VPN and L2VPN,
or both unicast VPN and multicast VPN, etc. Note that using the
procedures of RFC 4684, the Route Target (RT) membership NLRI used
for controlling distribution of VPNs routes cannot tell which kind of
Dong, et al. Expires April 19, 2010 [Page 3]
Internet-Draft BGP Based VPN Route Constrain October 2009
VPN routes are wanted. Thus in these scenarios, the procedures of RFC
4684 are not sufficient to provide precise control for VPN route
distribution, some PEs may receive unwanted VPN routes. Detailed
analyses are given in sections below.
3.1. Multiple VPNs with Different AFIs
Service providers may deploy multiple VPNs with different Address
Family Identifiers (AFI), such as IPv4 L3VPN (AFI=1), IPv6 L3VPN
(AFI=2) and L2VPN (AFI=25). When more than one of these kinds of VPNs
is deployed in the same network, using procedures of RFC 4684 can
lead to unwanted routes being received by some PEs.
3.1.1. IPv4 L3VPN and IPv6 L3VPN
Some service providers need to deploy both IPv4 L3VPN (VPNv4) and
IPv6 L3VPN (VPNv6) in their network. The RTs used for VPNv6 can be
the same as the ones for VPNv4. However, it's likely that not all the
VPN sites are both IPv4 and IPv6 capable, some of them may be only
IPv4 capable, some other ones may support both IPv4 and IPv6, and the
others can only recognize IPv6 packets.
In Figure 1, suppose the VPN site of VPN-1 connected to PE-1 is only
IPv4 capable, the sites of VPN-1 connected to PE-2 and PE-3 are IPv6
capable. Using procedures of RFC 4684, PE-1 advertises the RT
membership information of VPN-1 to the other PEs. According to the
received RT membership information, PE-2 and PE-3 will advertise
VPNv6 routes of VPN-1 to PE-1. As a result, PE-1 will receive
unwanted VPNv6 routes of VPN-1. Similarly, PE-1 can also receive
unwanted VPNv4 routes of VPN-2.
Dong, et al. Expires April 19, 2010 [Page 4]
Internet-Draft BGP Based VPN Route Constrain October 2009
+------------+ +------------+
| VPN-1 | | VPN-2 |
| | | |
| IPv4 | | IPv6 |
+------------+ +------------+
RT-1 \ / RT-2
+----------\------/----------+
| +----+ |
| Backbone |PE-1| |
| +----+ |
| | |
| +----+ |
| | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-2| |PE-3|----|------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ |IPv4 & IPv6 |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-1 | | VPN-1 |
| | | |
|IPv4 & IPv6 | | IPv6 |
+------------+ +------------+
Figure 1
Even if RTs allocated for VPNv6 are different from the ones used for
VPNv4 on each PE, there can be some overlapping between the RT space
of VPNv4 and VPNv6 in SP backbone network, in which case some PEs can
also receive unwanted VPN routes of other VPNs.
3.1.2. L3VPN and L2VPN
The mechanisms defined in RFC 4684 are claimed to be applicable for
L2VPNs which use Route Targets to control distribution of routing
information. However, if both L3VPN and L2VPN are deployed in the
same network, the mechanisms defined in RFC 4684 are not sufficient
for realizing accurate control of route distribution.
If there is some overlapping between the RT space of L3VPNs and
L2VPNs in the network, PEs will receive unwanted VPN routes of
another kind of VPN.
For example, in Figure 2, RT-1 is used by PE-1 and PE-4 for L2VPN-1,
and is also used by PE-2 and PE-3 for L3VPN-3. If PE-1 and PE-4
advertise RT membership information of RT-1 to other PEs in the
Dong, et al. Expires April 19, 2010 [Page 5]
Internet-Draft BGP Based VPN Route Constrain October 2009
network, subsequently PE-2 and PE-3 would advertise unwanted L3VPN
routes to PE-1 and PE-4.
+------------+ +------------+ +------------+
| VPN-1 | | VPN-2 | | VPN-3 |
| | | | | |
| L2VPN | | L3VPN | | L3VPN |
+------------+ +------------+ +------------+
RT-1 \ | RT-2 / RT-1
+---\--|----------------/----+
| +----+ +----+/ |
| |PE-1| |PE-2| |
| +----+ +----+ |
| \ / |
| \+----+/ |
| Backbone | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-3| |PE-4|-----------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ | L3VPN |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-3 | | VPN-1 |
| | | |
| L3VPN | | L2VPN |
+------------+ +------------+
Figure 2.
3.2. Multiple VPNs with Different SAFIs
When the AFI value is the same, different kinds of VPN routes are
further differentiated using Subsequent Address Family Identifiers
(SAFI). Such routes may be needed by different sets of PEs. However,
the procedures of RFC 4684 cannot describe the requirements of routes
with a particular SAFI.
For example, Multicast L3VPN [MVPN, MVPN-BGP] and VPLS multicast
[VPLS-MCAST] have defined new SAFIs for exchanging multicast routing
information, and Route Targets are also used in these scenarios to
control distribution of multicast routing information.
Since MVPN is deployed on the basis of unicast VPN, they are always
coexistent in the same network.
Dong, et al. Expires April 19, 2010 [Page 6]
Internet-Draft BGP Based VPN Route Constrain October 2009
As [MVPN-BGP] says, by default the distribution of Intra-AS I-PMSI A-
D route is controlled by the same Route Targets as the ones used for
the distribution of VPN-IP unicast routes. Thus PE advertising RT
membership NLRI may receive unwanted routing information, i.e., PE
wants to receive only unicast VPN routes corresponding to the RT may
also receive unwanted multicast routing information.
In Figure 3, suppose the site of VPN-1 connected to PE-1 only support
IP unicast, the sites of VPN-1 connected to PE-2 and PE-3 support IP
multicast. Using the mechanisms defined in [RFC 4684], PE-1 will
advertise the RT membership information of VPN-1 to the other PEs.
According to the received RT membership information, PE-2 and PE-3
will advertise multicast routes of VPN-1 to PE-1. As a result, PE-1
will receive unwanted multicast routes of VPN-1.
+------------+ +------------+
| VPN-1 | | VPN-2 |
| | | |
| Unicast | | Multicast |
+------------+ +------------+
RT-1 \ / RT-2
+----------\------/----------+
| +----+ |
| |PE-1| |
| +----+ |
| Backbone | |
| +----+ |
| | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-2| |PE-3|-----------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ | Unicast |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-1 | | VPN-1 |
| | | |
| Multicast | | Multicast |
+------------+ +------------+
Figure 3.
Even if RTs allocated for MVPNs are different from the ones used for
unicast VPNs on each PE, there can be some overlapping between the RT
space of MVPNs and unicast VPNs in the network, in which case some
PEs can also receive unwanted VPN routes of other VPNs.
Dong, et al. Expires April 19, 2010 [Page 7]
Internet-Draft BGP Based VPN Route Constrain October 2009
4. Considerations about Route Constraint in IPv6 L3VPN
The format of RT membership NLRI in RFC 4684 contains a Route Target
field of 8 octets. However, [IPv6-EXT-COMM] has defined IPv6 address
specific Route Target with the length of 20 octets, thus the format
of RT membership NLRI is not applicable when IPv6 address specific
Route Target is used. From this point of view, an update to the
format of RT-membership NLRI is necessary.
5. Considerations about Route Constraint in L1VPN
BGP is also used for L1VPN auto discovery as described in [RFC5195].
The SAFI value 69 has been assigned for L1VPN auto discovery
information. If route constrain procedures are used in L1VPN, then
deploying both L1VPN and other kinds of VPNs in the same network can
lead to problems similar to the examples in previous sections.
6. Proposed Solutions
This document proposes to extend RFC 4684 to a more general method
for controlling the route distribution of all kinds of BGP based VPNs
in any scenario.
6.1. Length of Route Target Field
First of all, this document proposes to change the length of Route
Target field in RT membership NLRI to "variable". Thus the NLRI
format is compatible with IPv6 address specific Route Target and
other new types of Route Targets which can be defined in future.
Since the RT membership NLRI is encoded as defined in section 4 of
RFC 2858 (which is obsoleted by [RFC4760]), thus the length field in
RT membership NLRI can be used to calculate the length of Route
Target.
6.2. Identifying RT Membership of Different VPNs
6.2.1. Identifying AFI of VPNs
In order to identify corresponding AFI of VPN routes that the RT
membership NLRI stands for, this document proposes to extend the AFI
value of RT membership NLRI. The AFI of this NLRI SHOULD be one of
the AFIs that use Route Target to control route distribution. In
order to be compatible with RFC 4684, this document defines a new
SAFI called Generalized Route Target Membership. A new SAFI value 135
needs to be assigned by IANA. Thus the [AFI, SAFI] value pair of the
Generalized RT Membership NLRI could be [AFI=1, SAFI=135] for IPv4
L3VPN, and [AFI=2, SAFI=135] for IPv6 L3VPN, and [AFI=25, SAFI=135]
Dong, et al. Expires April 19, 2010 [Page 8]
Internet-Draft BGP Based VPN Route Constrain October 2009
for L2VPN, etc. Since currently there is no fixed AFI value for L1VPN,
a new AFI value MAY need to be allocated by IANA, and the [AFI=TBD,
SAFI=135] value pair represents the Generalized RT membership NLRI of
L11VPN.
6.2.2. Identifying SAFI of VPNs
In order to distinguish the control of different types of VPN routes
with the same AFI value, e.g. unicast L3VPN and MVPN, or unicast
L2VPN and multicast L2VPN, the Generalized RT membership NLRI MUST
contain information about the SAFI value of the VPN routes being
requested. Thus the Generalized RT membership NLRI can be accurately
identified as RT information of one particular type of VPN route.
Besides, if L1VPN and other kinds of VPNs are deployed in the same
network, and no fixed AFI value has been allocated for L1VPN, the
SAFI value of L1VPN is needed to identify RT information of L1VPN.
6.2.3. Proposed Format of Generalized RT Membership NLRI
The format of Generalized RT membership NLRI is structured as follows:
+-------------------------------+
| Length (1 octet) |
+-------------------------------+
| Origin AS (4 octets) |
+-------------------------------+
| SAFI of VPN (1 octet) |
+-------------------------------+
| |
~ Route Target (variable) ~
| |
+-------------------------------+
The Length field is used to identify the total length of the rest
fields. [Author notes: Though this field is defined as "the length in
bits" in [RFC4760], it is RECOMMENDED that it represents the length
in octets of the rest fields as in [RFC4761] for convenience.]
The Origin AS field contains an Autonomous System number. Two octets
AS numbers are encoded in the two low order octets of the Origin AS
field, with the two high order octets set to zero.
The "SAFI of VPN" field is the SAFI value of the VPN routes the PE
wants to import using the Route Target below.
Dong, et al. Expires April 19, 2010 [Page 9]
Internet-Draft BGP Based VPN Route Constrain October 2009
The Route Target field contains Route Target of VPN routes being
requested. Note the length of the Route Target field is variable, and
can be calculated using the Length field of this NLRI.
7. Capability advertisement
In order for two BGP speakers to exchange Generalized RT membership
NLRI, they MUST use BGP Capabilities Advertisement to ensure that
they both are capable of properly processing such NLRI. This is done
as specified in [RFC4760], by using capability code 1 (multiprotocol
BGP) with an AFI of the corresponding VPN and an SAFI of 135.
8. Security Considerations
This document does not change the security properties of BGP based
VPNs and RFC 4684.
9. IANA Considerations
IANA needs to assign the SAFI value 135 for Generalized Route Target
Membership. This code point will come from the "Subsequent Address
Family Identifiers" registry.
IANA MAY assign an AFI number for L1VPN. This code point will come
from the "Address Family Numbers" registry.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D. and Rekhter, Y., "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P. et. al, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching
(BGP/MPLS) Internet Protocol (IP) Virtual Private Networks
(VPNs)", RFC 4684, November 2006.
Dong, et al. Expires April 19, 2010 [Page 10]
Internet-Draft BGP Based VPN Route Constrain October 2009
[RFC4760] Bates, T., Chandra, R., Katz, D., Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC5195] Ould-Brahim, H., Fedyk, D. and Rekhter, Y., "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[MVPN] Rosen, E., Aggarwal, R., "Multicast in MPLS/BGP IP VPNs", work
in progress
[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., Rekhter, Y., "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP VPNs",
work in progress.
10.2. Informative References
[IPv6-EXT-COMM] Rekhter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", work in progress.
[VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., "Multicast in VPLS",
work in progress.
[VPMS-BGP] Aggarwal, R., Kamite, Y., Jounay, F., "BGP based Virtual
Private Multicast Service Auto-Discovery and Signaling",
work in progress.
[L2VPN-SIG] Rosen, E., Luo, W., Davie, B., Radoaca, V., "Provisioning,
Autodiscovery, and Signaling in L2VPNs", work in progress.
Dong, et al. Expires April 19, 2010 [Page 11]
Internet-Draft BGP Based VPN Route Constrain October 2009
Authors' Addresses
Jie Dong
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: dongjie_dj@huawei.com
Mach(Guoyi) Chen
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: mach@huawei.com
Guiyan Liu
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.,
Hai-Dian District
Beijing, 100095
P.R. China
EMail: l62547@huawei.com
Hui Ni
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.,
Hai-Dian District
Beijing, 100095
P.R. China
EMail: nihui@huawei.com
Dong, et al. Expires April 19, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 05:53:31 |