Internet Engineering Task Force J. Scudder
Internet-Draft Juniper Networks
Intended status: Standards Track J. Uttaro
Expires: December 27, 2009 AT&T
P. Mohapatra
Cisco Systems
June 25, 2009
RT-Constrain Lite for Provider Edge Routers
draft-scudder-idr-rt-constrain-lite-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. 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.
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 December 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Scudder, et al. Expires December 27, 2009 [Page 1]
Internet-Draft RT-Constrain Lite June 2009
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.
Abstract
RFC 4684, "Constrained Route Distribution for Border Gateway
Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
(IP) Virtual Private Networks (VPNs)" provides a powerful and general
means for BGP speakers to exchange and propagate Route Target
reachability information which is used for cooperative route
filtering. However, the complexity of implementing the entire
specification may have impeded its widespread deployment. This
document specifies the subset of functionality which is required for
a provider edge router ("PE") to originate Route Target NLRI. Such
PEs need not implement any filtering functionality.
1. Introduction
[RFC4684], "Constrained Route Distribution for Border Gateway
Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
(IP) Virtual Private Networks (VPNs)" provides a powerful and general
means for BGP speakers to exchange and propagate Route Target
reachability information which is used for cooperative route
filtering. However, the complexity of implementing the entire
specification may have impeded its widespread deployment. We observe
that the functionality required for a BGP speaker functioning solely
as a provider edge router ("PE") is substantially simpler than that
required for a speaker which serves as a route reflector or ASBR.
Specifically, the PE need only implement the ability to send Route
Target Membership NLRI; it need not have the ability to receive,
store and filter upon such information.
This document specifies the subset of functionality which is required
for a PE to originate Route Target NLRI. Since this document simply
specifies a subset, any BGP implementation which conforms with
[RFC4684] by definition also conforms with this specification.
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].
Scudder, et al. Expires December 27, 2009 [Page 2]
Internet-Draft RT-Constrain Lite June 2009
2. Route Target Membership NLRI Advertisements
A PE implementing this specification advertises its Route Targets of
interest as Route Target membership NLRI in BGP UPDATE messages using
the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The
[AFI, SAFI] value pair used to identify this NLRI is (AFI=1,
SAFI=132).
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
of 0 to 96 bits, encoded as defined in Sections 3 and 4 of [RFC4760].
This prefix is structured as follows:
+-------------------------------+
| origin AS (4 octets) |
+-------------------------------+
| route target (8 octets) |
+ +
| |
+-------------------------------+
Except for the default route target, which is encoded as a zero-
length prefix, the minimum prefix length is 32 bits, since the origin
AS field cannot be interpreted as a prefix.
Although route targets can be expressed as prefixes as discussed in
[RFC4684], this specification does not mandate that such
functionality be provided. An implementation MAY choose to implement
the ability to advertise route target prefixes.
Although the default route target can be used to indicate to a peer
the willingness to receive all VPN route advertisements as discussed
in [RFC4684], this functionality is of dubious utility for a PE and
thus this specification does not mandate that such functionality be
provided. An implementation MAY choose to implement the ability to
advertise the default route target.
3. Capability Advertisement
A BGP speaker that wishes to advertise Route Target membership
information MUST use the Multiprotocol Extensions Capability
[RFC5492] Code, as defined in [RFC4760], to advertise the
corresponding (AFI, SAFI) pair, and MUST NOT advertise Route Target
membership information unless its peer has similarly advertised the
(AFI, SAFI) pair.
Scudder, et al. Expires December 27, 2009 [Page 3]
Internet-Draft RT-Constrain Lite June 2009
4. Operation
A BGP speaker implementing this specification MAY ignore all received
Route Target Membership NLRI routes. Such routes need not be stored,
they MAY be completely discarded without further processing. A
consequence of this is that a BGP speaker implementing this
specification MAY advertise its VPN NLRI without regard to what Route
Target membership information its peers may or may not have
advertised.
A BGP speaker implementing this specification MUST advertise a Route
Target Membership NLRI for each Route Target which it has been
configured to import into a local VRF. When the speaker's
configuration is updated to add or remove a Route Target import, the
speaker MUST generate Route Target Membership NLRI updates
(advertisements and/or withdrawals) to convey the necessary changes.
As a hint that initial RT membership exchange is complete,
implementations SHOULD generate an End-of-RIB marker, as defined in
[RFC4724], for the Route Target membership (afi, safi), regardless of
whether graceful restart is enabled on the BGP session.
5. Deployment Observations
We observe that when a BGP speaker supporting [RFC4684] and acting as
a route reflector ("the RR") peers with a BGP speaker which
implements this specification ("the PE"), the PE can be expected to
send all its VPN routes to the RR just as it would if no Cooperative
Route Filtering were in use. The RR would not be expected to apply
any filtering to those routes as a consequence of this specification
or [RFC4684]. However, the RR would be expected to build an outbound
filter towards the PE based on Route Target membership information
received from the PE. This is a consequence of the normal operation
of [RFC4684]; refer to that specification for more detail.
6. Acknowledgements
This document relies entirely on the functionality defined in
[RFC4684]. As such, thanks are due to the authors of that document.
Jim Guichard also made valuable contributions.
7. IANA Considerations
This memo includes no request to IANA.
Scudder, et al. Expires December 27, 2009 [Page 4]
Internet-Draft RT-Constrain Lite June 2009
8. Security Considerations
This specification makes no changes to the security considerations of
[RFC4684].
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009.
Authors' Addresses
John G. Scudder
Juniper Networks
Email: jgs@juniper.net
Jim Uttaro
AT&T
Email: uttaro@att.com
Pradosh Mohapatra
Cisco Systems
Email: pmohapat@cisco.com
Scudder, et al. Expires December 27, 2009 [Page 5]