L3VPN Working Group K. Patel
Internet-Draft R. Raszuk
Intended status: Standards Track Cisco Systems
Expires: April 21, 2011 M. Djernaes
Juniper Networks
J. Dong
M. Chen
Huawei Technologies Co., Ltd.
October 18, 2010
AFI Specific Route Target Distribution
draft-keyur-bgp-af-specific-rt-constrain-00.txt
Abstract
The current route target distribution specification described in
RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes.
Furthermore, the current specification mandates that Route Targets
exchanged using the current specification are applied towards
filtering for all VPN applications that uses the notion of Route
Target BGP extended communities.
In particular, the same Route Target distribution mechanism is used
to exchange VPNv4, VPNv6 and L2VPN prefixes. The IPv6 specific Route
Target extended community is defined in RFC5701 as length of 20
bytes. Since the current specification only supports prefixes of
maximum length of 12 bytes, the lack of an IPv6 specific Route Target
reachability information may be a problem when an operator wants to
use this application in a pure IPv6 environment. This document
defines an extension to the current constrained route distribution
specification that allows BGP speakers to distribute Route Target
prefixes using multiple different Address Families thereby limiting
the application of Route Target prefix filters to the specific
address family under which it is advertised. Furtheremore, this
document defines an extension that allows BGP to exchange longer
length IPv6 Route Target prefixes.
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/.
Patel, et al. Expires April 21, 2011 [Page 1]
Internet-Draft AFI Specific Route Target Distribution October 2010
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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Patel, et al. Expires April 21, 2011 [Page 2]
Internet-Draft AFI Specific Route Target Distribution October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. BGP Constrained Route Target Capability . . . . . . . . . . . . 4
3. AFI specific Route Target NLRI Advertisements . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Patel, et al. Expires April 21, 2011 [Page 3]
Internet-Draft AFI Specific Route Target Distribution October 2010
1. Introduction
The current constrained route distribution specification defined in
[RFC4684] supports prefixes with a fixed maximum length of 12 bytes.
Furthermore, the current specification mandates that the Route
Targets exchanged using the current specification are applied towards
filtering for all VPNv4, VPNv6, and L2VPN address families.
This behavior needs to be modified for the following reasons:
o The IPv6 specific Route Target extended community defined in
[RFC5701] is 20 bytes in length. Since the current specification
only supports prefixes of maximum length of 12 bytes, the lack of
an IPv6 specific Route Target reachability information may be a
problem when one wants to use this application in a pure IPv6
environment.
o The behavior of applying filtering for all VPN address families
(VPNv4, VPNv6 and L2VPN) is sub-optimal in cases where the
operators want to assign common Route Targets and perform scoped
filtering on an address family basis.
This document defines an extension to the current constrained route
distribution specification that allows BGP speakers to distribute
Route Target prefixes using multiple different Adddress Families
thereby limiting the application of Route Target filters to the
specific address family under which it is advertised. Address
families that do not exchange Route Target information using their
own AFI and SAFI = 132 MUST always use AFI=1 and SAFI=132 to exchange
their Route Targets and filter prefixes accordingly. Furthermore,
Address families that do exchange the Route Target information using
its own AFI and SAFI = 132 MUST override the Route Target information
received in AFI=1 and SAFI=132. In this way, the current extension
would preserve the backward compatibility with [RFC4684].
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 RFC 2119 [RFC2119].
2. BGP Constrained Route Target Capability
A BGP speaker that wishes to exchange Route Target membership
information for any address family must use the Multiprotocol
Extensions Capability Code, as defined in [RFC4760] section [5], to
advertise the corresponding (AFI, SAFI) pair.
Patel, et al. Expires April 21, 2011 [Page 4]
Internet-Draft AFI Specific Route Target Distribution October 2010
The BGP IPv6 Constrained Route Target capability is a new BGP
Capability [RFC5492] defined with Multiprotocol Extension Capability
code with AFI=2 and SAFI=132.
The BGP L2VPN Constrained Route Target capability is a new BGP
Capability [RFC5492] defined with Multiprotocol Extension Capability
code with AFI=25 and SAFI=132.
By advertising these capabilities to a peer, a BGP speaker conveys to
the peer that the speaker supports and can interpret appropriate
address family based Route Target reachability information and the
related procedures described in this document along with the
procedures described in [RFC4684]. When not present, the current
Constrained Route Target AFI=1 and SAFI=132 MUST apply to all the VPN
address families that did not exchanged the Constrained AFI specific
capability. Alternatively, the VPN address families that do
successful negotiation of newly defined Constrained Route Target
capabilities MUST override the Route Target information received in
the Constrained Route Target Address family of AFI=1 and SAFI=132.
In this way we make this specification fully backwards compatible
with the existing deployments.
3. AFI specific Route Target NLRI Advertisements
Route Target membership NLRI is advertised in BGP UPDATE messages
using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in
[RFC4760]. The [AFI, SAFI] value pair used to identify this NLRI is
(AFI=X,SAFI=132) where X describes the address family to which
Specific RT Constrained advertisement will apply.
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
of 0 to 24 octets, encoded as defined in Section 4 of [5] for all the
constrain route distribution AFI/SAFI other than AFI = 1 and SAFI =
132. The valid NLRI length value for AFI = 1 and SAFI = 132 is
defined in [RFC4684].
This prefix is structured as follows:
Patel, et al. Expires April 21, 2011 [Page 5]
Internet-Draft AFI Specific Route Target Distribution October 2010
+-------------------------------+
| origin as (4 octets) |
+-------------------------------+
| route target (8 or 20 octets)|
~ ~
| |
+-------------------------------+
Except for the default route target, which is encoded as a zero-
length prefix, the minimum prefix length is 32 bits. As the origin-
as field cannot be interpreted as a prefix.
Route targets can then be expressed as prefixes, where, for instance,
a prefix would encompass all route target extended communities
assigned by a given Global Administrator [6].
The default route target can be used to indicate to a peer the
willingness to receive all VPN route advertisements such as, for
instance, the case of a route reflector speaking to one of its PE
router clients.
4. Acknowledgements
The authors would like to thank Pedro Marques, John Scudder and Alton
Lo for discussions and review.
5. IANA Considerations
This draft does not require any new allocations by IANA. In all
address families constrained route target distribution will use the
already allocated SAFI = 132.
6. Security Considerations
This extension to [RFC4684] does not change the underlying security
issues inherent in the existing BGP and [RFC4684].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Patel, et al. Expires April 21, 2011 [Page 6]
Internet-Draft AFI Specific Route Target Distribution October 2010
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, November 2009.
7.2. Informative References
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
Authors' Addresses
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: keyupate@cisco.com
Robert Raszuk
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: raszuk@cisco.com
Patel, et al. Expires April 21, 2011 [Page 7]
Internet-Draft AFI Specific Route Target Distribution October 2010
Martine Djernaes
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: mdjernaes@juniper.net
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
Patel, et al. Expires April 21, 2011 [Page 8]