draft-ietf-l3vpn-acceptown-community-09.txt   draft-ietf-l3vpn-acceptown-community-10.txt 
Network Working Group J. Uttaro Network Working Group J. Uttaro
Internet-Draft ATT Internet-Draft ATT
Intended status: Standards Track P. Mohapatra Intended status: Standards Track P. Mohapatra
Expires: July 25, 2015 Sproute Networks Expires: December 26, 2015 Sproute Networks
D. Smith D. Smith
Cisco Systems Cisco Systems
R. Raszuk R. Raszuk
Mirantis Inc. Mirantis Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
January 21, 2015 June 24, 2015
BGP ACCEPT_OWN Community Attribute BGP ACCEPT_OWN Community Attribute
draft-ietf-l3vpn-acceptown-community-09.txt draft-ietf-l3vpn-acceptown-community-10.txt
Abstract Abstract
Under certain conditions it is desirable for a BGP route reflector to Under certain conditions it is desirable for a Border Gateway
be able to modify the Route Target list of a VPN route that is Protocol (BGP) route reflector to be able to modify the Route Target
distributed by the route reflector, enabling the route reflector to (RT) list of a Virtual Private Network (VPN) route that the route
control how a route originated within one VRF is imported into other reflector distributes, enabling the route reflector to control how a
VRFs. This technique works effectively as long as the VRF that route originated within one Virtual Routing and Forwarding (VRF) is
exports the route is not on the same PE as the VRF(s) that import the imported into other VRFs. This technique works effectively as long
route. However, due to the constraints of the BGP protocol, it does as the VRF that exports the route is not on the same Provider Edge
not work if the two are on the same PE. This document describes a (PE) router than the VRF(s) that import the route. However, due to
modification to the BGP protocol allowing this technique to work when the constraints of the BGP protocol, it does not work if the two are
the VRFs are on the same PE, allowing the technique to be used in a on the same PE. This document describes a modification to the BGP
standard manner throughout an autonomous system. protocol allowing this technique to work when the VRFs are on the
same PE, and to be used in a standard manner throughout an autonomous
system.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2015. This Internet-Draft will expire on December 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3 2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN Between Address Families . . . . . 4 2.2. Propagating ACCEPT_OWN Between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4 2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4 3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5 5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (non-informative) . . . . 6 Appendix A. Local Extranet Application (non-normative) . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
In certain scenarios, a BGP speaker may maintain multiple "VPN In certain scenarios, a BGP speaker may maintain multiple VRFs
Routing and Forwarding tables", or VRFs [RFC4364]. Under certain [RFC4364]. Under certain conditions, it is desirable for a route
conditions, it is desirable for a route reflector to be able to reflector to be able to modify the RT list of a VPN route that the
modify the Route Target (RT) list of a VPN route that is distributed route reflector distributes, enabling the route reflector to control
by the route reflector, enabling the route reflector to control how a how a route originated within one VRF is imported into other VRFs.
route originated within one VRF is imported into other VRFs. Though Though it is possible to perform such policy control directly on the
it is possible to perform such policy control directly on the
originator, it may be operationally cumbersome in an autonomous originator, it may be operationally cumbersome in an autonomous
system with a large number of border routers having complex BGP system with a large number of border routers having complex BGP
policies. policies.
The technique of the route reflector modifying the RT list works 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 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 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 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 the same PE. This is because per the BGP specification [RFC4271], a
BGP speaker rejects prefix advertisements received that were BGP speaker rejects prefix advertisements received that were
skipping to change at page 3, line 30 skipping to change at page 3, line 29
VRFs are on the same, or different PEs. VRFs are on the same, or different PEs.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. ACCEPT_OWN Community 2. ACCEPT_OWN Community
This memo defines a new BGP community from the First Come First This memo defines a new well-known BGP community from the First Come
Served range, ACCEPT_OWN, whose value as assigned by IANA is First Served range, ACCEPT_OWN, whose value as assigned by IANA is
0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be
controlled by configuration. The functionality SHOULD default to controlled by configuration. The functionality SHOULD default to
being disabled, as further specified in Section 2.3. being disabled, as further specified in Section 2.3.
2.1. Route Acceptance 2.1. Route Acceptance
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value 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 matches that of the receiving speaker if all of the following are
true: true:
skipping to change at page 4, line 10 skipping to change at page 4, line 10
o The route in question was originated from a source VRF on the o The route in question was originated from a source VRF on the
router. The source VRF is a VRF on the router whose configured router. The source VRF is a VRF on the router whose configured
Route Distinguisher is equal to the Route Distinguisher carried in Route Distinguisher is equal to the Route Distinguisher carried in
the route. the route.
o The route in question is targeted to one or more destination VRFs o The route in question is targeted to one or more destination VRFs
on the router (as determined by inspecting the Route Target(s)). on the router (as determined by inspecting the Route Target(s)).
o At least one destination VRF is different from the source VRF. o 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 A route MUST NOT ever be accepted back into its source VRF, even if
carries one or more Route Targets (RTs) which match that VRF. it carries one or more RTs which match that VRF.
2.2. Propagating ACCEPT_OWN Between Address Families 2.2. Propagating ACCEPT_OWN Between Address Families
The ACCEPT_OWN community controls propagation of routes which can be The ACCEPT_OWN community controls propagation of routes which can be
associated with a source VRF by inspection of their Route associated with a source VRF by inspection of their Route
Distinguisher and with a target 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 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 SHOULD NOT be attached to any routes which cannot be associated with
a source VRF. This implies that when propagating routes into a VRF, a source VRF. This implies that when propagating routes into a VRF,
the ACCEPT_OWN community should not be propagated. Likewise, if a the ACCEPT_OWN community SHOULD NOT be propagated. Likewise, if a
route carrying the ACCEPT_OWN community is received in an address route carrying the ACCEPT_OWN community is received in an address
family which does not allow the source VRF to be looked up, the family which does not allow the source VRF to be looked up, the
ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be
logged in this case. logged in this case.
2.3. Configuration Control 2.3. Configuration Control
ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD ACCEPT_OWN handling SHOULD be controlled by configuration, and if
default to being disabled. When ACCEPT_OWN is disabled by controlled by configuration, it MUST default to being disabled. When
configuration (either explicitly or by default), the router MUST NOT ACCEPT_OWN is disabled by configuration (either explicitly or by
apply the special route acceptance rules detailed in Section 2.1. default), the router MUST NOT apply the special route acceptance
The router SHOULD still apply the propagation rules detailed in rules detailed in Section 2.1. The router SHOULD still apply the
Section 2.2. propagation rules detailed in Section 2.2.
3. Decision Process 3. Decision Process
If a BGP speaker supports ACCEPT_OWN and is configured for the If a BGP speaker supports ACCEPT_OWN and is configured for the
extensions defined in this document, the following step is inserted extensions defined in this document, the following step is inserted
after the LOCAL_PREF comparison step in BGP decision process: after the LOCAL_PREF comparison step in BGP decision process:
When comparing a pair of routes for a BGP destination, the route When comparing a pair of routes for a BGP destination, the route
attached with ACCEPT_OWN community is preferred over the route attached with ACCEPT_OWN community is preferred over the route
that does not have the community. that does not have the community.
In all other respects, the decision process remains unchanged. This In all other respects, the decision process remains unchanged. This
extra step MUST only be invoked during the best path selection extra step MUST only be invoked during the best path selection
process of VPN-IP routes [RFC4364] (i.e. it MUST NOT be invoked for process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for
the best path selection of "imported" IP routes in a VRF). The the best path selection of "imported" IP routes in a VRF). The
purpose of the extra step is to allow the paths advertised by the purpose of the extra step is to allow the paths advertised by the
route reflector with ACCEPT_OWN community to be selected as best over route reflector with ACCEPT_OWN community to be selected as best over
other paths that the BGP speaker may have received, hence enabling other paths that the BGP speaker may have received, hence enabling
the applications ACCEPT_OWN is designed for. the applications ACCEPT_OWN is designed for.
4. Deployment Considerations 4. Deployment Considerations
The ACCEPT_OWN community as described in this document is useful The ACCEPT_OWN community as described in this document is useful
within a single autonomous system which uses a single layer of route within a single autonomous system which uses a single layer of route
skipping to change at page 5, line 36 skipping to change at page 5, line 36
construct allows a route's originator to associate that route with construct allows a route's originator to associate that route with
its source context, and "Route Target" should be understood to mean its source context, and "Route Target" should be understood to mean
whatever construct allows a route to be targeted for import into a whatever construct allows a route to be targeted for import into a
context other than its source. context other than its source.
6. Security Considerations 6. Security Considerations
ACCEPT_OWN as described above permits a router's own route prefix to 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, 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 such a route is similar to any other BGP route and shares the same
set of security vulnerabilities and concerns. No new fundamental set of security vulnerabilities and concerns. This extension does
security issues are introduced by ACCEPT_OWN. not change the underlying security issues inherent in BGP VPN
[RFC4364].
7. IANA Considerations 7. IANA Considerations
IANA has assigned the value 0xFFFF0001 from BGP well-known IANA has assigned the value 0xFFFF0001 from BGP well-known
communities registry for ACCEPT_OWN community. No additional IANA communities registry for ACCEPT_OWN community. No additional IANA
action is required. action is required.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence
skipping to change at page 6, line 19 skipping to change at page 6, line 21
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
Appendix A. Local Extranet Application (non-informative) Appendix A. Local Extranet Application (non-normative)
One of the applications for this behavior is auto-configuration of One of the applications for this behavior is auto-configuration of
extranets within MPLS VPN networks. Consider the following topology: extranets within MPLS VPN networks. Consider the following topology:
CE1 --------+ CE1 --------+
| |
(VRF 1, RD 1, RT 1) (VRF 1, RD 1, RT 1)
PE1 ................... RR PE1 ................... RR
(VRF 2, RD 2, RT 2) (VRF 2, RD 2, RT 2)
| |
 End of changes. 14 change blocks. 
38 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/