Network Working Group E. Chen
Internet Draft K. Patel
Intended Status: Standards Track A. Lo
Expiration Date: June 6, 2012 Cisco Systems
December 5, 2011
Extended Community Based Outbound Route Filter for BGP-4
draft-chen-bgp-ext-community-orf-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 6, 2012.
Copyright Notice
Copyright (c) 2011 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
Chen, Patel & Lo [Page 1]
Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011
described in the Simplified BSD License.
Abstract
This document defines two new Outbound Router Filter types for BGP,
termed "Extended Community Outbound Route Filter Type I", and
"Extended Community Outbound Route Filter Type II", that can be used
to perform extended community based route filtering.
1. Introduction
The Outbound Route Filtering Capability defined in [RFC5291] provides
a mechanism for a BGP speaker to send to its BGP peer a set of
Outbound Route Filters (ORFs) that can be used by its peer to filter
its outbound routing updates to the speaker.
This document defines two new Outbound Router Filter type for BGP
[RFC4271], termed "Extended Community Outbound Route Filter Type I",
and "Extended Community Outbound Route Filter Type II", that can be
used to perform the extended community [RFC4360, RFC5760] based route
filtering. The former can be used only for the 8-octet extended
communities defined in [RFC4360], and is retained for backward
compatibility. The latter can be used for the extended communities
defined in both [RFC4360] and [RFC5701]. This document also
specifies procedures for performing route filtering when both types
are supported.
1.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 [RFC2119].
Chen, Patel & Lo [Page 2]
Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011
2. Extended Communities ORF Type I
The Extended Community ORF Type I allows to express ORFs in terms of
the 8-octet BGP Extended Communities defined in [RFC4360]. That is,
the Extended Communities ORF Type I provides the 8-octet Extended
Community based route filtering.
Conceptually the ORF entry of the Extended Communities ORF Type I
consists of a single Extended Community of 8 octets.
The sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
The remote peer should consider only those routes whose Extended
Communities attribute has at least one Extended Community in common
with the Extended Communities list specified in the ORF.
2.1. Encoding
The value of the ORF-Type for the Extended Communities ORF Type I is
3.
The type-specific part of the Extended Communities ORF Type I
consists of a single Extended Community as specified in [RFC4360].
3. Extended Communities ORF Type II
The Extended Community ORF Type II allows to express ORFs in terms of
the BGP Extended Communities defined in both [RFC4360] and [RFC5701].
That is, the Extended Communities ORF Type II provides Extended
Community based route filtering.
Conceptually the ORF entry of the Extended Communities ORF-Type
consists of a single Extended Community, of either 8 octets, or 20
octets.
The sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
The remote peer should consider only those routes whose Extended
Communities attribute has at least one Extended Community in common
with the Extended Communities list specified in the ORF.
Chen, Patel & Lo [Page 3]
Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011
3.1. Encoding
The value of the ORF-Type for the Extended Communities ORF Type II is
<TBD>.
The type-specific part of the Extended Communities ORF Type II
consists of a single Extended Community encoded as the following
+------------------------------------------+
| Ext-community Length (1 octet) |
+------------------------------------------+
| Ext-community value (8 or 20 octets) |
+------------------------------------------+
where the "Ext-community Length" field contains the number of octets
of the extended community in the "Ext-community value" field.
4. Operations
In addition to the general procedures defined in [RFC5291], the
following procedures are specified for the Extended Community ORF
types.
As the Extended Community ORF Type I can only handled the extended
communities defined in [RFC4360], clearly it SHOULD NOT be enabled
over a BGP session that exchanges routes with the extended
communities defined in [RFC5701].
The Extended Community ORF Type I is retained for backward
compatibility. An implementation SHOULD migrate to the Extended
Community ORF Type II in order to handle the extended communities
defined in both [RFC4360] and [RFC5701].
During the lifetime of a BGP session, ORF entries of only one of the
two types would be carried in the ROUTE-REFRESH message, and be used
in route filtering. When both types are allowed, respectively, by
the "Send/Receive" fields in the Outbound Route Filtering Capability
and the procedures specified in [RFC5291], Type II would be used.
When only one of the two types is allowed by the "Send/Receive"
fields in the Outbound Route Filtering Capability and the procedures
specified in [RFC5291], that particular type would be used.
Chen, Patel & Lo [Page 4]
Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011
5. IANA Considerations
This document specifies two new Outbound Route Filtering (ORF) types,
Extended Community ORF Type I (with ORF-type value 3), and the
Extended Community ORF Type II (with ORF-type value <TBD>).
6. Security Considerations
This extension to BGP does not change the underlying security issues
in BGP [RFC4271].
7. Acknowledgements
We would like to thank Yakov Rekhter for his contribution on this
work.
8. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended
Community Attribute", RFC 5701, November2009.
[RFC5291] Chen, E., and Rekhter, Y., "Outbound Route Filtering
Capability for BGP-4", RFC 5291, August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Chen, Patel & Lo [Page 5]
Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011
9. Author Information
Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
EMail: enkechen@cisco.com
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: keyupate@cisco.com
Alton Lo
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: altonlo@cisco.com
Chen, Patel & Lo [Page 6]