Network Working Group James Uttaro
Internet Draft AT&T
Expiration Date: December 2008
Pradosh Mohapatra
David J. Smith
Cisco Systems, Inc.
Robert Raszuk
John Scudder
Juniper Networks, Inc.
June 8, 2008
BGP ACCEPT_OWN Well-known Community Attribute
draft-pmohapat-l3vpn-acceptown-community-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Abstract
Under certain conditions it is desirable for a BGP route reflector to
be able to modify the Route Target list of a VPN route that is
distributed by the route reflector, enabling the route reflector to
control how a route originated within one VRF is imported into other
Uttaro, et al. [Page 1]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
VRFs. This technique works effectively as long as the VRF that
exports the route is not on the same PE as the VRF(s) that import the
route. However, due to the constraints of the BGP protocol, it does
not work if the two are on the same PE.
This document describes a modification to the BGP protocol allowing
this technique to work when the VRFs are on the same PE, allowing the
technique to be used in a standard manner throughout an autonomous
system.
Table of Contents
1 Specification of Requirements ...................... 2
2 Introduction ....................................... 3
3 ACCEPT_OWN Community ............................... 3
3.1 Route Acceptance ................................... 4
3.2 Propagating ACCEPT_OWN Between Address Families .... 4
3.3 Configuration Control .............................. 4
4 Deployment Considerations .......................... 5
5 Other Applications ................................. 5
6 Security Considerations ............................ 5
7 IANA Considerations ................................ 5
8 Appendix A - Extranet application (non-normative) .. 6
9 Acknowledgements ................................... 7
10 Normative References ............................... 7
11 Authors' Addresses ................................. 7
12 Full Copyright Statement ........................... 8
13 Intellectual Property .............................. 8
1. Specification of Requirements
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].
Uttaro, et al. [Page 2]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
2. Introduction
In certain scenarios, a BGP speaker may maintain multiple "VPN
Routing and Forwarding tables", or VRFs [RFC4364]. Under certain
conditions it is desirable for a route reflector to be able to modify
the Route Target (RT) list of a VPN route that is distributed by the
route reflector, enabling the route reflector to control how a route
originated within one VRF is imported into other VRFs. Though it is
possible to perform such policy control directly on the originator,
it may be operationally cumbersome in an autonomous system with a
large number of border routers having complex BGP policies.
The technique of the route reflector modifying the RT list works
effectively as long as the VRF that exports the route is not on the
same PE as the VRF(s) that import the route. However, due to the
constraints of the BGP protocol, it does not work if the two are on
the same PE. This is because per the BGP specification [RFC4271], a
BGP speaker rejects prefix advertisements received that were
originated by itself. In an autonomous system with route reflectors,
the route reflector attaches the ORIGINATOR_ID attribute to the
UPDATE messages so that if such prefix advertisements reach the
originator, the originator can reject them by simply checking the
ORIGINATOR_ID attribute. The BGP specification also mandates that a
route should not be accepted from a peer when the NEXT_HOP attribute
matches the receiver's own "IP address".
This document proposes a modification to BGP's behavior by defining a
new well-known community [RFC1997] value, in order to allow the
technique of RT list modification by the route reflector to be used
in a standard manner throughout an autonomous system, irrespective of
whether the VRFs are on the same, or different PEs.
3. ACCEPT_OWN Community
This memo defines a new well-known BGP community, ACCEPT_OWN, with
value 0xFFFFFF05. Processing of the ACCEPT_OWN community SHOULD be
controlled by configuration. The functionality SHOULD default to
being disabled, as further specified in Section 3.3.
Uttaro, et al. [Page 3]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
3.1. Route Acceptance
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value
matches that of the receiving speaker if all of the following are
true:
+ Processing of the ACCEPT_OWN community is enabled by
configuration.
+ The route in question carries the ACCEPT_OWN community.
+ The route in question was originated from a source VRF on the
router (as determined by inspecting the Route Distinguisher).
+ The route in question is targeted to one or more destination VRFs
on the router (as determined by inspecting the Route Target(s)).
+ At least one destination VRF is different from the source VRF.
A route MUST never be accepted back into its source VRF, even if it
carries one or more Route Targets (RTs) which match that VRF.
3.2. Propagating ACCEPT_OWN Between Address Families
The ACCEPT_OWN community controls propagation of routes which can be
associated with a source VRF by inspection of their Route
Distinguisher and with a target VRF by inspection of their Route
Target list (for example VPN routes with a SAFI of 128). As such, it
SHOULD NOT be attached to any routes which cannot be associated with
a source VRF. This implies that when propagating routes into a VRF,
the ACCEPT_OWN community should not be propagated. Likewise, if a
route carrying the ACCEPT_OWN community is received in an address
family which does not allow the source VRF to be looked up, the
ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be
logged in this case.
3.3. Configuration Control
ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD
default to being disabled. When ACCEPT_OWN is disabled by
configuration (either explicitly or by default), the router MUST NOT
apply the special route acceptance rules detailed in Section 3.1.
The router SHOULD still apply the propagation rules detailed in
Section 3.2.
Uttaro, et al. [Page 4]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
4. Deployment Considerations
The ACCEPT_OWN community as described in this document is useful
within a single autonomous system which uses a single layer of route
reflectors. Its use with hierarchical route reflectors would require
further specification and is out of scope for this document.
Likewise, its use across multiple autonomous systems is out of scope
for this document.
5. Other Applications
This approach may also be relevant to other scenarios where a BGP
speaker maintains multiple routing contexts using an approach
different from that of [RFC4364], as long as the specific approach in
use has the property that the BGP speaker originates and receives
routes within a particular context. In such a case, "VRF" in this
document should be understood to mean whatever construct provides a
routing context in the specific technology under consideration.
Likewise, "Route Distinguisher" should be understood to mean whatever
construct allows a route's originator to associate that route with
its source context, and "Route Target" should be understood to mean
whatever construct allows a route to be targeted for import into a
context other than its source.
6. Security Considerations
ACCEPT_OWN as described above permits a router's own route prefix to
be advertised to a different VRF on that router. In this respect,
such a route is similar to any other BGP route and shares the same
set of security vulnerabilities and concerns. No new fundamental
security issues are introduced by ACCEPT_OWN.
7. IANA Considerations
This document defines a new well-known community, called ACCEPT_OWN.
It is to be assigned value 0xFFFFFF05.
Uttaro, et al. [Page 5]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
8. Appendix A - Extranet application (non-normative)
One of the applications for this behavior is auto-configuration of
extranets within MPLS VPN networks. Consider the following topology:
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
Within the above topology, PE1 receives a prefix X from CE1. Prefix X
is installed in VRF 1 and is advertised to the route reflector with
route distinguisher (RD) 1 and route target (RT) 1 as configured on
PE1. The requirement is to import prefix X into VRF 2 and advertise
it to CE2 in support of extranet VPN connectivity between CE1/VRF1
and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require
changing the import RT value and/or import policy for VRF 2 on PE1.
This is operationally cumbersome in a network with a large number of
border routers having complex BGP policies.
Alternatively, using the new ACCEPT_OWN community value, the route
reflector can simply re-advertise prefix X back to PE1 with RT 2
appended. In this way, PE1 will accept prefix X despite its
ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of
RT 2, and will then determine the correct adjacency rewrite within
VRF 1 based on the RD value (1) and the prefix. Note that the RT 1
value originally attached to the route will simply be ignored since
associated with the source VRF 1. The same operation needs also to
happen in the reverse direction (VRF 1 learning a route from VRF 2)
to achieve establishment of an extranet VPN strictly via the route
reflector without changing the BGP policy of PE1 in any way.
A router performing such an extranet application can accept a route
with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which
the router originated the route is different than the VRF in which
the router accepts the re-advertised route.
Uttaro, et al. [Page 6]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
9. Acknowledgements
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence
Filsfils, John Mullooly, and Jeff Haas for their valuable comments
and suggestions.
10. Normative References
[RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border
Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," March 1997.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
11. Authors' Addresses
James Uttaro
AT&T
200 S. Laurel Avenue
Middletown, NJ 07748
Email: uttaro@att.com
Pradosh Mohapatra
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
Email: pmohapat@cisco.com
David J. Smith
Cisco Systems, Inc.
111 Wood Avenue South
Iselin, NJ 08830
E-mail: dasmith@cisco.com
Uttaro, et al. [Page 7]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
Robert Raszuk
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: raszuk@juniper.net
John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: jgs@juniper.net
12. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Uttaro, et al. [Page 8]
Internet Draft draft-pmohapat-l3vpn-acceptown-community-00.txt June 2008
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Uttaro, et al. [Page 9]