Internet DRAFT - draft-xu-l3vpn-prefix-constrain
draft-xu-l3vpn-prefix-constrain
Network Working Group X. Xu
Internet-Draft M. Chen
Intended status: Standards Track Huawei
Expires: July 27, 2014 January 23, 2014
Address Prefix Based VPN Route Distribution Constrain
draft-xu-l3vpn-prefix-constrain-00
Abstract
This document defines MP-BGP procedures that allow BGP speakers to
exchange VPN route interest information. This information can be
used to control VPN route distribution at the granularity of address
prefix, which is applicable in the context of Virtual Subnet and may
also be applicable in other BGP/MPLS IP VPN environments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 27, 2014.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Xu & Chen Expires July 27, 2014 [Page 1]
Internet-Draft January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. VPN Route Interest Advertisement . . . . . . . . . . . . . . 3
4. Capability Advertisement . . . . . . . . . . . . . . . . . . 4
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Route Target Contrain mechanism defined in [RFC4684] allows a BGP
speaker to control VPN route distribution by using the received Route
Target membership information. However, in some network environments
where the amount of VPN routes is too large, it's usually expected to
control the VPN route distribution at a finer granulurity (e.g., VPN
address prefix). In other word, it's expected to support the pull-
mode for VPN route distribution at a finer granurility.
This document builds on the concept of on-demand VPN route
distribution asdescribed in [RFC4684] and defines new procedures that
allow BGP speakers to exchange VPN route interest information. This
information can be used to control VPN route distribution at the
granularity of address prefix. This fine-grained VPN route
distribution control is applicable in the context of Virtual Subnet
[I-D.xu-l3vpn-virtual-subnet] and may also be applicable in other BGP
/MPLS IP VPN [RFC4364] environments.
1.1. Requirements Language
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].
2. Terminology
This memo makes use of the terms defined in [RFC2858] and [RFC4364].
Xu & Chen Expires July 27, 2014 [Page 2]
Internet-Draft January 2014
3. VPN Route Interest Advertisement
VPN Route Interest NLRI is advertised in BGP UPDATE messages using
the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The
[AFI, SAFI] value pair for VPNv4 Route Interest NLRI is (AFI=1,
SAFI=TBD1), and the [AFI, SAFI] value pair for VPNv6 Route Interest
NLRI is (AFI=2, SAFI=TBD1). The Next Hop field of MP_REACH_NLRI
attribute shall be interpreted as an IPv4 address whenever the length
of NextHop address is 4 octets, and as a IPv6 address whenever the
length of the NextHop address is 16 octets. The NLRI field in the
MP_REACH_NLRI and MP_UNREACH_NLRI contains the IPv4 or IPv6 address
prefix part of a VPN address prefix which is interesting to the
originator of such NLRI. In other word, the Route Distinguisher (RD)
part of that VPN address prefix is not contained. A Route Target
extended community is attached to the NLRI to indicate the VPN
instance that the above IPv4 or IPv6 address prefix belongs to.
In order to restrict the propagation scope of VPN route interest
information, the VPN Route Interest NLRI containning a VPN route of a
particular VPN SHOULD only be propagated to those BGP peers which
maintain routes for that VPN. That's to say, the exact propagation
of the VPN Route Interest NLRI is built upon the discovery of the
export Route Target membership Information. Note that the export
Route Target membership information here is different from the
(import) Route Target membership information as described in
[RFC4684], since the former expresses the semantic of "I have VPN
routes associated with a particular Route Target" while the latter
expresses the semantic of "I want VPN routes associated with a
particular Route Target". To disthguish them from each other, the
export Route Target membership information SHOULD be conveyed in a
different NLRI (AFI=1, SAFI=TBD2) other than that (AFI=1, SAFI=132)
for conveying the (import) Route Target membership information. The
advertisement procedure for export Route Target membership
information is the same as that for the (import) Route Target
membership information except that the former is used for controlling
the propagation of VPN Route Interest NLRIs while the latter is used
for controlling the propagation of VPN routes. Of course, the export
Route Target membership informaiton can also be used to control the
propagation of the (import) Route Target membership information if
desired. In this way, the (import) Route Target membership
information expressing the semantic of "I want VPN route of a given
Route Target X" would only be propagated to those BGP peers who have
indicated that they have VPN routes for Route Target X by advertising
the export Route Target membership information.
A VPN Route Interest NLRI SHOULD only be advertised to a peer that
participates in the exchange of VPN route interest information if
that peer has advertised either the default export Route Target
Xu & Chen Expires July 27, 2014 [Page 3]
Internet-Draft January 2014
membership NLRI or a export Route Target membership NLRI containing
any of the targets contained in the extended communities attribute of
the VPN route interest NRLI in question. In other word, the export
Route Target membership information is used to restrict the
distribution of the VPN route interest information (at the Route
Target granularity) which in turn is used to control the VPN route
distribution (at the address prefix granularity). The address
prefix-based VPN route distribution control based upon the VPN Route
Interest NRLIs could be used together with the Route Target-based
route distribution control based upon the (import) Route Target
Membership NLRIs. For instance, a BGP speaker may want its peer to
send all routes for VPN red and some particular routes for VPN blue.
It is NOT RECOMMENDED to propagate a VPN Route Interest NLRI
associated with a given Route Target towards a peer to whom an
"import" Route Target membership NLRI containing the said Route
Target has been sent before.
4. Capability Advertisement
A BGP speaker that wishes to exchange VPN Route Interest information
MUST use the Multiprotocol Extensions Capability Code, as defined in
[RFC2858], to advertise the corresponding (AFI, SAFI) pair. Since
the exact propagation of the VPN Route Interest Information depends
on the pre-progagation of the export Route Target membership
Information, the Capability for the export Route Target membership
NLRI (AFI=1, SAFI=TBD2) MUST be supported as a prerequisite.
5. Operations
A VPN route SHOULD be advertised to a peer that participates in the
exchange of VPN route interest information if that peer has
advertised a VPN Route Interest NLRI containing the the same IPv4 or
IPv6 address prefix as that of the VPN route in question and the
Route Target of that VPN route is the same as the Route Target
associated with that VPN Route Interest NLRI. Note that here the RD
part of the VPN route SHOULD be ignored when performing the VPN route
search. When a BGP speaker receives a BGP UPDATE that advertises or
withdraws a given VPN Route Interest NLRI, it SHOULD examine the RIB-
OUTs of VPN NLRIs and re-evaluate the advertisement status of routes
that match the VPN Route Interest NLRI in question. A BGP speaker
SHOULD generate the minimum set of BGP VPN route updates
(advertisements and/or withdrawls) necessary to transition between
the previous and current state of the route distribution graph that
is derived from VPN Route Interest information. As a hint that
initial VPN Route Interest Information exchange is complete,
implementations SHOULD generate an End-of-RIB marker, as defined in
[RFC4724], for the VPN Route Interest information (AFI=1 or 2,
SAFI=TBD1), regardless of whether graceful-restart is enabled on the
Xu & Chen Expires July 27, 2014 [Page 4]
Internet-Draft January 2014
BGP session. This allows the receiver to know when it has received
the full contents of the peer's VPN Route Interest information. The
exchange of VPN NLRI SHOULD follow the receipt of the End-of-RIB
markers. If a BGP speaker chooses to delay the advertisement of BGP
VPN route updates until it receives this End-of-RIB marker, it MUST
limit that delay to an upper bound. By default, a 60 second value
SHOULD be used. Similarly, the exchange of VPN Route Interest NLRI
SHOULD folow the receipt of the End-of-RIB markers for the export
Route Target Membership NLRI (AFI=1, SAFI=TBD2).
6. Acknowledgements
The authors would like to thank ... for their comments on this
document.
7. IANA Considerations
The SAFI codes for VPNv4 and VPNv6 Route Interest needs to be
assigned respectively by the IANA.
8. Security Considerations
This document does not introduce any new security risk to the BGP/
MPLS IP VPN.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
Xu & Chen Expires July 27, 2014 [Page 5]
Internet-Draft January 2014
9.2. Informative References
[I-D.xu-l3vpn-virtual-subnet]
Building, K., Hares, S., Yongbing, F., Jacquenet, C.,
Boyes, T., and B. Fee, "Virtual Subnet: A L3VPN-based
Subnet Extension Solution", draft-xu-l3vpn-virtual-
subnet-02 (work in progress), November 2013.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Authors' Addresses
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Xu & Chen Expires July 27, 2014 [Page 6]