IDR Working Group R. Raszuk
Internet-Draft Cisco Systems
Intended status: Standards Track H. Gredler
Expires: January 5, 2011 Juniper Networks
July 4, 2010
Wide BGP Communities
draft-raszuk-wide-bgp-communities-00
Abstract
Communicating various routing policies via route tagging plays an
important role in external BGP peering relations. The most common
tool used today to attach various information about routes is
realized with the use of BGP communities. Such information is
important for the peering AS to perform some mutually agreed actions
without the need to maintain a separate offline database for each
pair of prefix and an associated with it requested set of action
entries.
The problem arises for customers which are assigned a 4 octet AS
numbers as current definition of BGP communities are of total of 4
octets in length.
This document proposes the solution to this problem by defining new
type of BGP Extended Community attribute which is to be used to pass
routing policy information between peers. Such new type could be
used to pass existing routing policies which are communicated today
by Internet Service Providers in standard BGP Community Attribute
which have two octet AS numbers as well as those which already got
assigned 4 octet AS numbers from their respected Internet routing
registries.
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/.
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."
Raszuk & Gredler Expires January 5, 2011 [Page 1]
Internet-Draft wide-bgp-communities July 2010
This Internet-Draft will expire on January 5, 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.
Raszuk & Gredler Expires January 5, 2011 [Page 2]
Internet-Draft wide-bgp-communities July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Wide BGP Community . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Wide BGP Community . . . . . . . . . . . . . . . . . . . . 5
3. Globally significant pre-defined values . . . . . . . . . . . 7
3.1. Well Known Standard BGP Communities . . . . . . . . . . . 7
3.2. Registered pre-defined Wide BGP Communities . . . . . . . 7
3.2.1. General Registered Wide BGP Communities . . . . . . . 8
3.2.2. Advertisement control Registered Wide BGP
Communities . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. AS source marking Registered Wide BGP Communities . . 12
3.2.4. Return path influencing Registered Wide BGP
Communities . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. AS_PATH modifying Registered Wide BGP Communities . . 14
3.2.6. Geographic source marking Registered Wide BGP
Communities . . . . . . . . . . . . . . . . . . . . . 16
3.2.7. Local Preference Registered Wide BGP Communities . . . 17
3.2.8. AS_PATH TTL Registered Wide BGP Communities . . . . . 18
4. Encoding examples . . . . . . . . . . . . . . . . . . . . . . 19
5. Operational considerations . . . . . . . . . . . . . . . . . . 20
6. Security considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Raszuk & Gredler Expires January 5, 2011 [Page 3]
Internet-Draft wide-bgp-communities July 2010
1. Introduction
RFC 1997 [RFC1997] defines a BGP Community Attribute to be used as a
tool to contain in BGP update message various additional information
about routes which may help to automate peering administration. As
defined in RFC 1997 [RFC1997] BGP Communities attribute consists of
one or more sets of four octet values, where each one of them
specifies a different community. Except two reserved ranges the
encoding of community values mandates that first two octets are to
contain the Autonomous System number followed by next two octets
containing locally defined value.
With the introduction of 4-octet Autonomous System numbers by RFC
4893 [RFC4893] it became obvious that BGP Communities as specified in
RFC 1997 will not be able to accommodate new AS encoding. In fact
RFC 4893 explicitly recommends use of four octets AS specific
extended communities as a way to encode new 4 octet AS numbers.
Unfortunately both the RFC 4893 as well as proposal for new extended
community encoding which would contain 4 octet AS numbers do not
define a new sub-type value which would allow to carry routing
policies in BGP extended communities. Authors believe that defining
a new regular type of BGP Extended Communities for both two-octet and
four-octet Autonomous System addresses a real operational problem of
today's networks or of internet exchange points operators.
While defining a new type of any tool there is always a unique
opportunity to specify a subset of well recognized behaviors. Second
part of this document lists the most commonly used today BGP
communities as well as provides a new registry for future
definitions.
2. Wide BGP Community
The BGP Extended Communities attribute as defined in RFC 4360
[RFC4360] is a transitive optional BGP attribute with the Type Code
16 and consists of a set of extended communities of the following
format:
Raszuk & Gredler Expires January 5, 2011 [Page 4]
Internet-Draft wide-bgp-communities July 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low(*) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(*) Present for Extended types only, used for the Value field
otherwise.
Figure1: The Extended Community Attribute
For the purposes of encoding for Wide BGP Communities a new extended
community type has been defined below.
2.1. Wide BGP Community
Wide BGP Community is a BGP Extended Community of a regular type with
Type Field comprising of 1 octet and Value Field comprising of 7
octets.
Wide BGP Community is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x06 or 0x46 | ACTIONS | 2 or 4 octet AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 or 4 octet AS number | Community Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure2: Wide BGP Community
For the purpose of scoping propagation of Wide BGP Communities across
Autonomous System boundaries document recommends to define two
values. The value of the high type of this regular extended
community is 0x06 which indicates transitiveness across Autonomous
System boundaries and 0x46 to indicate non-transitiveness across an
Autonomous System boundary. *Values are to be confirmed by IANA*
The remaining 7 octets are encoded as follows:
ACTIONS: 1 octet
Raszuk & Gredler Expires January 5, 2011 [Page 5]
Internet-Draft wide-bgp-communities July 2010
1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+
| ACTIONS |
+---+---+---+---+---+---+---+---+
Figure2: Wide BGP Community Actions 1 octet
The Actions octet allows for explicit indication of the requested
execution meaning or level of attached Wide BGP Community value.
0x00 - Default action. No special handling.
0x01 - Informational Only Support Indicator - Used to signal that
attached Wide BGP Community is supported by given Autonomous
System. That is particularly useful for AS specific Wide BGP
Communities which are to be executed on remote transit domains or
target domains. No execution is required on Wide BGP Communities
propagate with this Action flag.
0x02 - Mandatory Execution - Indicates that an action encoded in
attached Wide BGP Community is of mandatory execution type and
therefor if given community is recognized it must be executed. If
not executed for example due to local policy the bgp update
message containing such Wide BGP Community must be dropped.
However it needs to be pointed that as BGP communities are
optional by design and therefor could be filtered at any network
boundary the semantics of this action do not change that. The
specified action does not change the base definition of BGP
communities.
0x03..0x7F - Reserved for future extensions
0x80..0xFF - Open for operator's own use
2 or 4 octet Autonomous System number: 4 octets
The Autonomous System number which indicates the originator of
given Wide BGP Community or the target Autonomous System number
given Wide BGP Community may be referring to.
When Autonomous System is a two octet number the first two octets
of this 4 octet value are to be filled with zeros.
Two special values are reserved in the Autonomous System number
field: 0x00000000 - to indicate "None of Autonomous Systems" and
value of 0xFFFFFFFF - to indicate "All of Autonomous Systems".
The detailed interpretation will be provided when describing each
Raszuk & Gredler Expires January 5, 2011 [Page 6]
Internet-Draft wide-bgp-communities July 2010
given community type which would intend to utilize the reserved
Autonomous System number.
Community Value: 2 octets
The Wide BGP Community value encoded in this field indicates
private or registered Wide BGP Community type which defines what
set of actions a router is requested or recommended to take upon
reception of routes with such tags.
3. Globally significant pre-defined values
3.1. Well Known Standard BGP Communities
According to RFC 1997 as well as to IANA's Well-Known BGP Communities
registry today the following BGP communities are defined to have
global significance:
0xFFFF0000 planned-shut [draft-francois-bgp-gshut]
0xFFFFFF01 NO_EXPORT [RFC1997]
0xFFFFFF02 NO_ADVERTISE [RFC1997]
0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997]
0xFFFFFF04 NOPEER [RFC3765]
This document recommends for simplicity as well as for avoidance of
backward compatibility issues the continued use of BGP Standard
Community Attribute type 8 as defined in RFC 1997 to distribute non
Autonomous System specific Well-Known BGP Communities.
3.2. Registered pre-defined Wide BGP Communities
It has been requested numerous times to have a globally unified way
to express some particular Autonomous System based routing policies.
When defining a new way to encode bgp communities we have an
opportunity to define set of new registered routing policies and
route markings which could be passed between Autonomous Systems
resulting in their common interpretation.
This document will request IANA to define and maintain a new registry
for pre-defined Wide BGP Communities. The reserved pool of AS#:
0xB000-0xFFFF (20479 values) has been defined for their allocations.
The allocation policy is on a first come first served basis.
It is recommended that an implementation supports by an explicit
Raszuk & Gredler Expires January 5, 2011 [Page 7]
Internet-Draft wide-bgp-communities July 2010
enabling all defined below Registered Wide BGP Communities.
Depending on the BGP implementation support it is recommended that an
implementation would support Registered Wide BGP Communities without
breaking static or dynamic peer/update groups. However it needs to
be pointed out that support of all Registered Wide BGP Communities is
not mandatory. It will be perfectly valid for any BGP implementation
to support only subset of Wide BGP Communities.
It is strongly advised that each Autonomous System does an inbound
verification of received Wide BGP Communities from all of its EBGP
peers before accepting them and propagating within their own domain.
The document does not mandate nor enforces that given registered type
value of Wide BGP Community would be of transitive 0x06 or non-
transitive 0x46 type. It is for the operator to determine the
propagation scope of such community when appending it to routing
information. However the document will provide a transitiveness
scope recommendation to defined communities.
The following Wide BGP Communities have global significance and their
execution should be uniformly implemented by any BGP speaker
supporting given set of Wide BGP Communities.
In general there are two kinds of semantics for Autonomous System
number present in the body of Registered Wide BGP Community: SRC_AS
which indicates that the value corresponds to the Autonomous System
number which constructed and appended given community and PARAM_AS
which indicates that execution of given community is depended on
evaluation of Autonomous System number present in this community.
Unless explicitly indicated otherwise the Autonomous System number
inserted into Wide BGP Communities are of SRC_AS type.
3.2.1. General Registered Wide BGP Communities
Format:
NAME (type_code)
Recommended scope of use: local-domain or multi-domain.
Recommended post execution action: "execute and drop" or "execute
and forward" or "N/A".
Description.
SRC_AS:BLACKHOLE (AS:0xB000)
Raszuk & Gredler Expires January 5, 2011 [Page 8]
Internet-Draft wide-bgp-communities July 2010
Scope: multi-domain.
Post exec: execute and forward.
All transit traffic to destinations for which advertised routes
carry such Wide BGP Community containing this value should be
dropped. It is recommended that specified Autonomous System
number should be eligible and verified by BGP Origin Validation
functionality to advertise given BGP destinations.
SRC_AS:BLACKHOLE_FROM_PEER (AS:0xB001)
Scope: multi-domain.
Post exec: execute and forward.
All transit traffic to destinations for which advertised routes
carry such Wide BGP Community containing this value should be
dropped when coming from peers. It is recommended that specified
Autonomous System number should be eligible and verified by BGP
Origin Validation functionality to advertise given BGP
destinations.
SRC_AS:BLACKHOLE_FROM_UPSTREAM (AS:0xB002)
Scope: multi-domain.
Post exec: execute and forward.
All transit traffic to destinations for which advertised routes
carry such Wide BGP Community containing this value should be
dropped when coming from upstream providers. It is recommended
that specified Autonomous System number should be eligible and
verified by BGP Origin Validation functionality to advertise given
BGP destinations.
SRC_AS:SOURCE_BLACKHOLE (AS:0xB003)
Scope: multi-domain.
Post exec: execute and forward.
All transit traffic which source addresses have been tagged by
such Wide BGP Community should be dropped. It is recommended that
specified Autonomous System number should be eligible and verified
by BGP Origin Validation functionality to advertise given BGP
destinations.
Raszuk & Gredler Expires January 5, 2011 [Page 9]
Internet-Draft wide-bgp-communities July 2010
SRC_AS:SOURCE_DO_RPF (AS:0xB004)
Scope: multi-domain.
Post exec: execute and forward.
All transit traffic which source addresses have been tagged by
such Wide BGP Community should be subject to Reverse Path
Forwarding check when crossing Autonomous System boundaries.
Autonomous System number specified in the body of this community
should directly indicate the peering interfaces on which such RPF
check should be performed.
SRC_AS:HIGH_PRIORITY_PREFIX (AS:0xB005)
Scope: local-domain.
Post exec: N/A (tagging only).
BGP prefixes carrying such Wide BGP Community should be advertised
to restarting peers before other prefixes received by given BGP
speaker.
SRC_AS:ATTACK_TARGET (AS:0xB006)
Scope: multi-domain.
Post exec: N/A (tagging only)
The ATTACK_TARGET Registered Wide BGP Community indicates that BGP
prefixes carrying such community are receiving unusual amount of
unwanted traffic most likely due to some form of network attack.
Network devices capable of analyzing and mitigating such attacks
can use such community as a hint on what destinations to focus the
most.
3.2.2. Advertisement control Registered Wide BGP Communities
PARAM_AS:NO_ADVERTISE (AS:0xB080)
Scope: multi-domain.
Post exec: N/A - Entire update get's dropped.
All routes received which carry such Wide BGP Community containing
this value MUST NOT be advertised to BGP peer which Autonomous
System number has been listed in the body of this community.
Raszuk & Gredler Expires January 5, 2011 [Page 10]
Internet-Draft wide-bgp-communities July 2010
Semantically specifying the reserved Autonomous System value of
0xFFFFFFFF (Any AS) would be an equivalent of using NO_ADVERTISE
Well-Known Standard BGP Community Attribute.
PARAM_AS:ADVERTISE_TO (AS:0xB081)
Scope: multi-domain.
Post exec: execute and drop.
All routes received carrying such Wide BGP Community containing
this value MUST ONLY be advertised to BGP peer which Autonomous
System number is specified in the body of this community.
SRC_AS:ADVERTISE_NO_PEER (AS:0xB082)
Scope: multi-domain.
Post exec: execute and drop
All routes advertised by an Autonomous System carrying such Wide
BGP Community containing this value should NOT be advertised to
any of its peering partners.
SRC_AS:ADVERTISE_NO_UPSTREAM (AS:0xB083)
Scope: multi-domain.
Post exec: execute and drop
All routes advertised by an Autonomous System carrying such Wide
BGP Community containing this value should NOT be advertised to
any of its upstream providers.
SRC_AS:ADVERTISE_NO_CUSTOMER (AS:0xB084)
Scope: multi-domain.
Post exec: execute and drop
All routes advertised by an Autonomous System carrying such Wide
BGP Community containing this value should NOT be advertised to
any of its customers.
PARAM_AS:ADVERTISE_TO_SET_NO_EXPORT (AS:0xB085)
Raszuk & Gredler Expires January 5, 2011 [Page 11]
Internet-Draft wide-bgp-communities July 2010
Scope: multi-domain.
Post exec: execute and drop
All routes received carrying such Wide BGP Community containing
this value MUST ONLY be advertised to BGP peer which Autonomous
System number is specified in the body of this community. If not
already present during advertisement NO_EXPORT Standard BGP
Community should be inserted.
3.2.3. AS source marking Registered Wide BGP Communities
SRC_AS:FROM_PEER (AS:0xB100)
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes received
from their EBGP peers to later, when advertising them outside the
domain, apply or relax local policies only on such group of
destinations.
SRC_AS:FROM_CUSTOMER (AS:0xB101)
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes received
from their EBGP peers to later, when advertising them outside the
domain, apply or relax local policies only on such group of
destinations.
SRC_AS:INTERNAL (AS:0xB102)
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes originated
in their own domain to later, when advertising them outside the
domain, apply or relax local policies only on such group of
destinations.
SRC_AS:FROM_UPSTREAM (AS:0xB103)
Raszuk & Gredler Expires January 5, 2011 [Page 12]
Internet-Draft wide-bgp-communities July 2010
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes received
from their EBGP peers to later, when advertising them outside the
domain, apply or relax local policies only on such group of
destinations.
SRC_AS:FROM_IX (AS:0xB104)
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes received
from their EBGP peering sessions with the Internet Exchange peers
or with Route Server to later, when advertising them outside the
domain, apply or relax local policies only on such group of
destinations.
PARAM_AS:LEARNED_FROM (AS:0xB105)
Scope: local-domain.
Post exec: N/A (tagging only)
Autonomous System may attach this community to routes received
from their EBGP peer by explicitly tagging routes with their
peer's Autonomous System number instead of inserting their own
local AS number.
3.2.4. Return path influencing Registered Wide BGP Communities
PARAM_AS:PATH_HINT (AS:0xB180)
Scope: multi-domain.
Post exec: execute and forward.
Autonomous System receiving such Wide BGP Community value should
prefer for BGP prefixes received with such community (for example
by increasing value of local preference on ingress), a BGP path
which traverses Autonomous System number which has been specified
in this community.
PARAM_AS:PATH_NEGATIVE_HINT (AS:0xB181)
Raszuk & Gredler Expires January 5, 2011 [Page 13]
Internet-Draft wide-bgp-communities July 2010
Scope: multi-domain.
Post exec: execute and forward.
Autonomous System receiving such Wide BGP Community value should
prefer for BGP prefixes received with such community (for example
by decreasing value of local preference on ingress), a BGP path
which DOES NOT traverses Autonomous System number which has been
specified in the body of this community.
3.2.5. AS_PATH modifying Registered Wide BGP Communities
PARAM_AS:PREPEND_BY (AS:0xB200..0xB20F)
Scope: multi-domain.
Post exec: execute and drop.
The Autonomous System specified in the body of such Wide BGP
Community should prepend 1..15 times its own Autonomous System
number when advertising routes tagged with this community to all
of its external peers. Value of 0xB200 indicates the support for
AS:PREPEND_BY Wide BGP Community and values of 0xB201..0xB20F
indicate the required number of 1..15 prepended Autonomous System
numbers.
PARAM_AS:PREPEND_TO (AS:0xB210..0xB21F)
Scope: multi-domain.
Post exec: execute and drop.
A BGP domain receiving routes tagged with this community should
prepend 1..15 times its own Autonomous System number when
advertising them to an Autonomous System indicated in the body of
this community. Value of 0xB210 indicates the support for AS:
PREPEND_TO Wide BGP Community and values of 0xB211..0xB21F
indicate the required number of 1..15 prepended Autonomous System
numbers. After execution this community should be removed from
further bgp propagation.
SRC_AS:PREPEND_UPSTREAM (AS:0xB220..0xB22F)
Scope: multi-domain.
Post exec: execute and drop.
Raszuk & Gredler Expires January 5, 2011 [Page 14]
Internet-Draft wide-bgp-communities July 2010
An Autonomous System when advertising routes tagged with this
community value should prepend 1..15 times its own Autonomous
System number when advertising them to all of its upstream
providers. Value of 0xB220 indicates the support for AS:
PREPEND_UPSTREAM Wide BGP Community and values of 0xB221..0xB22F
indicate the required number of 1..15 prepended Autonomous System
numbers. This community should not be propagated to EBGP
neighbors.
SRC_AS:PREPEND_PEERS (AS:0xB230..0xB23F)
Scope: multi-domain.
Post exec: execute and drop.
An Autonomous System advertising routes tagged with this community
should prepend 1..15 times its own Autonomous System number when
advertising them to all of its peers. Value of 0xB230 indicates
the support for AS:PREPEND_PEERS Wide BGP Community and values of
0xB231..0xB23F indicate the required number of 1..15 prepended
Autonomous System numbers. This community should not be
propagated to EBGP neighbors.
SRC_AS:PREPEND_CUSTOMERS (AS:0xB240..0xB24F)
Scope: multi-domain.
Post exec: execute and drop.
An Autonomous System advertising routes tagged with this community
should prepend 1..15 times its own Autonomous System number when
advertising them to all of its customers. Value of 0xB240
indicates the support for AS:PREPEND_CUSTOMERS Wide BGP Community
and values of 0xB241..0xB24F indicate the required number of 1..15
prepended Autonomous System numbers. This community should not be
propagated to EBGP neighbors.
PARAM_AS:REPLACE_BY (AS:0xB250)
Scope: multi-domain.
Post exec: execute and drop.
All routes marked with such Wide BGP Community advertised by an
Autonomous System to all of its external peers should have any
occurrence of an Autonomous System number specified replaced with
advertising domain's local Autonomous System number. After
execution this community should be removed from further bgp
Raszuk & Gredler Expires January 5, 2011 [Page 15]
Internet-Draft wide-bgp-communities July 2010
propagation.
3.2.6. Geographic source marking Registered Wide BGP Communities
SRC_AS:PEER_ROUTE (AS:0xB280..0xB28F)
Scope: local-domain or multi-domain.
Post exec: N/A (tagging only).
Autonomous System may mark routes received from their peers by
constructing Wide BGP Community to contain their Autonomous System
number and well-known pre-defined geographic localization
community value as per below mapping table:
0xB280 - North America
0xB281 - Central America
0xB282 - South America
0xB283 - Europe
0xB284 - Asia
0xB285 - Japan
0xB286 - ANZ
0xB287 - Africa
0xB288 - Unspecified Region
0xB289 .. 0xB28F - Free
SRC_AS:UPSTREAM_ROUTE (AS:0xB290..0xB29F)
Scope: local-domain or multi-domain.
Post exec: N/A (tagging only).
Autonomous System may mark routes received from their upstreams by
constructing Wide BGP Community to contain their Autonomous System
number and well-known pre-defined geographic localization
community value as per below mapping table:
Raszuk & Gredler Expires January 5, 2011 [Page 16]
Internet-Draft wide-bgp-communities July 2010
0xB290 - North America
0xB291 - Central America
0xB292 - South America
0xB293 - Europe
0xB294 - Asia
0xB295 - Japan
0xB296 - ANZ
0xB297 - Africa
0xB298 - Unspecified Region
0xB299 .. 0xB29F - Free
SRC_AS:CUSTOMER_ROUTE (AS:0xB2A0..0xB2AF)
Scope: local-domain or multi-domain.
Post exec: N/A (tagging only).
Autonomous System may mark routes received from their customers by
constructing Wide BGP Community to contain their Autonomous System
number and well-known pre-defined geographic localization
community value as per below mapping table:
0xB2A0 - North America
0xB2A1 - Central America
0xB2A2 - South America
0xB2A3 - Europe
0xB2A4 - Asia
0xB2A5 - Japan
0xB2A6 - ANZ
0xB2A7 - Africa
0xB2A8 - Unspecified Region
0xB2A9 .. 0xB2AF - Free
3.2.7. Local Preference Registered Wide BGP Communities
SRC_AS:LOCAL_PREF (AS:0xB300..0xB30F)
Scope:multi-domain.
Post exec: execute and drop.
Autonomous System may suggest to its EBGP neighbor the following
relative adjustments to the value of local preference as specified
by given domain's local policy. The below table indicates the
values of recommended increment and decrement local preference
normalized by X. X is used by local domain operator to normalize
absolute increment or decrement values for a given policies.
Raszuk & Gredler Expires January 5, 2011 [Page 17]
Internet-Draft wide-bgp-communities July 2010
0xB300 - Used to indicate support for AS:LOCAL_PREF
0xB301 - Decrement Local Pref by X*20
0xB302 - Decrement Local Pref by X*40
0xB303 - Decrement Local Pref by X*60
0xB304 - Decrement Local Pref by X*80
0xB305 - Decrement Local Pref by X*100
0xB306 - Increment Local Pref by X*20
0xB307 - Increment Local Pref by X*40
0xB308 - Increment Local Pref by X*60
0xB309 - Increment Local Pref by X*80
0xB30A - Increment Local Pref by X*100
0xB30B - Unallocated
0xB30C - Unallocated
0xB30D - Unallocated
0xB30E - Unallocated
0xB30F - Unallocated
3.2.8. AS_PATH TTL Registered Wide BGP Communities
SRC_AS:AS_PATH_TTL (AS:0xB310..0xB31F)
Scope: multi-domain.
Post exec: execute and forward.
Autonomous System may suggest to drop advertised prefix by any
transit network if its AS_PATH attribute length would be equal or
greater to encoded value both inbound or outbound of EBGP session.
The below table indicates the value of recommended encoding of
AS_PATH length which should result in prefix drop:
Raszuk & Gredler Expires January 5, 2011 [Page 18]
Internet-Draft wide-bgp-communities July 2010
0xB310 - Used to indicate support for AS:AS_PATH_TTL
0xB311 - Drop if AS_PATH >= 1
0xB312 - Drop if AS_PATH >= 2
0xB313 - Drop if AS_PATH >= 3
0xB314 - Drop if AS_PATH >= 4
0xB315 - Drop if AS_PATH >= 5
0xB316 - Drop if AS_PATH >= 6
0xB317 - Drop if AS_PATH >= 7
0xB318 - Drop if AS_PATH >= 8
0xB319 - Drop if AS_PATH >= 9
0xB31A - Drop if AS_PATH >= 10
0xB31B - Drop if AS_PATH >= 11
0xB31C - Drop if AS_PATH >= 12
0xB31D - Drop if AS_PATH >= 13
0xB31E - Drop if AS_PATH >= 14
0xB31F - Drop if AS_PATH >= 15
4. Encoding examples
The 0xBBBB non mandatory and transitive Wide BGP Community encoding
by AS 1 would be of below form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x06 | 0x00 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0xBBBB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The same 0xBBBB Wide BGP Community, but non-transitive and mandatory
encoding by AS 131072 would be of below form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x46 | 0x80 | 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0xBBBB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Raszuk & Gredler Expires January 5, 2011 [Page 19]
Internet-Draft wide-bgp-communities July 2010
5. Operational considerations
Having two different ways to propagate locally assigned BGP
communities, one via use of Standard BGP Community attribute and the
other one via use of Wide BGP Community may seem to potentially cause
problems when considering propagation of conflicting actions.
However it needs to be noticed and pointed out that today even within
Standard BGP Communities operator or operators may append similar
conflicting information to already existing community propagation
tool set.
It is therefor recommended that any implementation when supporting
both standard and wide BGP communities will allow for their easy
inbound and outbound policing. For the actual execution all
communities should be treated as union and if supported by an
implementation their execution permission are to be a local
configuration matter.
When advertising as well as during insertion of Wide BGP Communities
which are predefined as range of values - only use of one value of
selected range is allowed.
6. Security considerations
All the security considerations for BGP Communities as well as for
BGP Extended Communities RFCs apply here.
7. IANA Considerations
This document defines a new regular type of BGP Extended Communities
Attribute called Wide BGP Communities. For this new type IANA is to
allocate new type values in the corresponding registries:
Registry Name: BGP Extended Communities Type - regular, transitive
This document makes the following assignments for the regular,
transitive Wide BGP Communities:
Name Type Value
---- ----------
Wide BGP Community 0x06
Registry Name: BGP Extended Communities Type - regular, non-
Raszuk & Gredler Expires January 5, 2011 [Page 20]
Internet-Draft wide-bgp-communities July 2010
transitive
This document makes the following assignments for the regular, non-
transitive Wide BGP Communities:
Name Type Value
---- ----------
Wide BGP Community 0x46
This document requests IANA to define and maintain a new registry
named: "Registered Wide BGP Communities Actions". The reserved pool
of AS#:0x00-0x80 has been defined for its allocations. The
allocation policy is on a first come first served basis.
This document makes the following assignments for the Registered Wide
BGP Community Actions values:
Name Type Value
---- ----------
Default action 0x00
Informational Only Support Indicator 0x01
Mandatory 0x02
Reserved for further allocations 0x03..0x7F
Open for operator's own use 0x80..0xFF
This document requests IANA to define and maintain a new registry
named: "Registered Wide BGP Communities Values". The reserved pool
of AS#:0xB000-0xFFFF has been defined for its allocations. The
allocation policy is on a first come first served basis.
This document makes the following assignments for the Registered Wide
BGP Community values:
Name Type Value
---- ----------
BLACKHOLE 0xB000
BLACKHOLE_FROM_PEER 0xB001
BLACKHOLE_FROM_UPSTREAM 0xB002
SOURCE_BLACKHOLE 0xB003
SOURCE_DO_RPF 0xB004
Raszuk & Gredler Expires January 5, 2011 [Page 21]
Internet-Draft wide-bgp-communities July 2010
HIGH_PRIORITY_PREFIX 0xB005
ATTACK_TARGET 0xB006
General_Free_Pool 0xB007..0xB07F
NO_ADVERTISE 0xB080
ADVERTISE_TO 0xB081
ADVERTISE_NO_PEER 0xB082
ADVERTISE_NO_UPSTREAM 0xB083
ADVERTISE_NO_CUSTOMER 0xB084
ADVERTISE_TO_SET_NO_EXPORT 0xB085
Advertising_Free_Pool 0xB086..0xB0FF
FROM_PEER 0xB100
FROM_CUSTOMER 0xB101
INTERNAL 0xB102
FROM_UPSTREAM 0xB103
FROM_IX 0xB104
LEARNED_FROM 0xB105
Marking_Free_Pool 0xB106..0xB17F
PATH_HINT 0xB180
PATH_NEGATIVE_HINT 0xB181
Path_Control_Free_Pool 0xB182..0xB1FF
PREPEND_BY 0xB201..0xB20F
PREPEND_TO 0xB211..0xB21F
PREPEND_UPSTREAM 0xB221..0xB22F
PREPEND_PEERS 0xB231..0xB23F
PREPEND_CUSTOMERS 0xB241..0xB24F
REPLACE_BY 0xB250
AS_Path_Modify_Free_Pool 0xB251..0xB27F
PEER_ROUTE 0xB280..0xB28F
UPSTREAM_ROUTE 0xB290..0xB29F
CUSTOMER_ROUTE 0xB2A0..0xB2AF
Geo_Free_Pool 0xB2B0..0xB2FF
LOCAL_PREF 0xB300..0xB30A
Local_Pref_Unallocated 0xB30B..0xB30F
AS_PATH_TTL 0xB310..0xB31F
Free_Pool 0xB320..0xFFFF
Raszuk & Gredler Expires January 5, 2011 [Page 22]
Internet-Draft wide-bgp-communities July 2010
8. Contributors
The following people contributed significantly to the content of the
document:
Bruno Decraene
France Telecom
38-40 rue du General Leclerc
92794 Issi Moulineaux cedex 9
France
Email: bruno.decraene@orange-ftgroup.com
Shintaro Kojima
OTEMACHI 1st. SQUARE EAST TOWER, 3F
1-5-1, Otemachi,
Chiyoda-ku, Tokyo 100-0004
Japan
Email: koji@mfeed.ad.jp
Juan Alcaide
Cisco Systems
Research Triangle Park, NC
United States
Email: jalcaide@cisco.com
Burjiz Pithawala
Cisco Systems
170 West Tasman Dr
San Jose, CA
United States
Email: bpithaw@cisco.com
Saku Ytti
TDC Oy
Mechelininkatu 1a
00094 TDC
Finland
Email: ytti@tdc.net
Raszuk & Gredler Expires January 5, 2011 [Page 23]
Internet-Draft wide-bgp-communities July 2010
9. Acknowledgments
Authors would like to thank Enke Chen, Keyur Patel, Pedro Marques and
Alton Lo for their valuable input.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "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.
10.2. Informative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC1998] Chen, E. and T. Bates, "An Application of the BGP
Community Attribute in Multi-home Routing", RFC 1998,
August 1996.
[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114,
RFC 4384, February 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, October 2009.
Authors' Addresses
Robert Raszuk
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: raszuk@cisco.com
Raszuk & Gredler Expires January 5, 2011 [Page 24]
Internet-Draft wide-bgp-communities July 2010
Hannes Gredler
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
US
Email: hannes@juniper.net
Raszuk & Gredler Expires January 5, 2011 [Page 25]
