IDR Working Group R. Raszuk, Ed.
Internet-Draft NTT MCL Inc.
Intended status: Standards Track J. Haas, Ed.
Expires: January 14, 2013 Juniper Networks
S. Amante
Level 3 Communications, LLC
R. Steenbergen
nLayer Communications, Inc.
B. Decraene
France Telecom
P. Jakma
Uni. of Glasgow
July 13, 2012
Wide BGP Communities Attribute
draft-raszuk-wide-bgp-communities-03
Abstract
Route tagging plays an important role in external BGP [RFC4271]
relations, in communicating various routing policies between peers.
It is also a very common best practice among operators to propagate
various additional information about routes intra-domain. The most
common tool used today to attach various information about routes is
through the use of BGP communities [RFC1997].
Such information is important to allow BGP speakers to perform some
mutually agreed upon actions without the need to maintain a separate
offline database for each tuple of prefix and associated set of
action entries.
This document defines a new encoding which will enhance and simplify
what can be accomplished today with the use of BGP communities. The
most important addition this specification makes over currently
defined BGP communities is the ability to specify, carry as well as
use for execution an operator's defined set of parameters. It also
provides an extensible platform for any new community encoding needs
in the future.
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].
Status of this Memo
Raszuk, et al. Expires January 14, 2013 [Page 1]
Internet-Draft wide-bgp-communities July 2012
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."
This Internet-Draft will expire on January 14, 2013.
Copyright Notice
Copyright (c) 2012 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, et al. Expires January 14, 2013 [Page 2]
Internet-Draft wide-bgp-communities July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Wide BGP Community Attribute . . . . . . . . . . . . . . . . . 4
2.1. Wide BGP Community Attribute Container Header . . . . . . 5
2.2. Wide Community Atoms . . . . . . . . . . . . . . . . . . . 6
3. Container Type 1: Wide Community . . . . . . . . . . . . . . . 8
3.1. Community Value . . . . . . . . . . . . . . . . . . . . . 8
3.2. Source AS Number . . . . . . . . . . . . . . . . . . . . . 8
3.3. Context AS Number . . . . . . . . . . . . . . . . . . . . 8
3.4. Wide Community Target(s) TLV . . . . . . . . . . . . . . . 9
3.5. Wide Community Parameter(s) TLV . . . . . . . . . . . . . 9
3.6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Well Known Standard BGP Communities . . . . . . . . . . . . . 10
5. Operational considerations . . . . . . . . . . . . . . . . . . 11
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Example Wide Community Definition . . . . . . . . . . . . 11
6.2. Example Wide Community Encoding . . . . . . . . . . . . . 12
7. Security considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Raszuk, et al. Expires January 14, 2013 [Page 3]
Internet-Draft wide-bgp-communities July 2012
1. Introduction
RFC 1997 [RFC1997] defines the BGP Community Attribute. This
attribute is used as a tool to carry additional information in BGP
routes which may help to automate peering administration. The BGP
Communities Attribute consists of one or more sets of four octet
values, where each specifies a different community. Except for two
reserved ranges, the encoding of community values mandates that the
first two octets are to contain the Autonomous System number, with
the next two octets containing some 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
[RFC5668] extended communities [RFC4360] as a way to encode new 4
octet AS numbers.
While the encoding of 4 octet AS numbers is being addressed by
[draft-ietf-idr-as4octet-extcomm-generic-subtype], neither the base
BGP communities (standard or extended) nor as4octet-extcomm-generic
document define a sufficient level of encoding freedom which could be
of practical use. The authors believe that defining a new BGP Path
Attribute, with the ability to contain locally defined parameters
will enhance the current level of network policies, as well as
simplify BGP policy management. The proposed simple encoding will
also facilitate the delivery of new network services without a need
to define a new BGP extension each time.
When defining any new type of tool there is always a unique
opportunity to specify a subset of well recognized behaviors. Lists
of the current most commonly used BGP communities, as well as
provision for a new registry for future definitions will be contained
in a separate document.
2. Wide BGP Community Attribute
This document defines a new BGP Path Attribute, the Wide BGP
Community. The attribute type code is (TBA by IANA).
The Wide BGP Community Attribute is an optional, transitive BGP
attribute, and may be present only once in the update message.
The attribute contains a number of typed containers. Any given
container type may appear multiple times, unless that container
type's definition specifies otherwise.
Raszuk, et al. Expires January 14, 2013 [Page 4]
Internet-Draft wide-bgp-communities July 2012
2.1. Wide BGP Community Attribute Container Header
Containers always start with the following header:
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 | Flags | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+------+-------+----------------------------------------------------+
| Bit | Value | Meaning |
+------+-------+----------------------------------------------------+
| 0 | 0 | Local community value. |
| | 1 | Registered community value. |
| 1 | 0 | Do not decrement Hop Count field across |
| | | confederation boundaries. |
| | 1 | Decrement Hop Count field across confederation |
| | | boundaries. |
| 2..7 | - | SHOULD be zero. |
+------+-------+----------------------------------------------------+
Flags are defined globally, to apply to all wide community container
types.
Table 1: Flags
Bit 0 set (value 1) indicates that the given container carries a Wide
BGP Community which is registered with IANA. When not set (value 0)
it indicates that community value which follows is locally assigned
with a local meaning. Ignored bits SHOULD be preserved in any
received containers, or set to 0 otherwise.
Bit 1 is used to manage the propagation scope of a given Wide BGP
Community across confederation boundaries. When not set (value of
0), the Hop Count field is not considered at the sub-AS boundaries.
When set (value of 1), sub-AS border router follows the same
procedure regarding the handling of the Hop Count field as applicable
to ASBR at the domain boundary.
The Hop Count field represents the forwarding radius, in units of AS
hops, for the given Wide BGP Community. A Hop Count value of zero
indicates that this wide community must not cross any further AS
boundaries. At each AS boundary, when propagating a given wide
community over an EBGP session, the Hop Count field MUST be
Raszuk, et al. Expires January 14, 2013 [Page 5]
Internet-Draft wide-bgp-communities July 2012
decremented by the sending EBGP speaker.
The exact same decrement procedures described above apply also to
sub-confederation boundaries when the bit 1's flag is set to 1.
The special value of 0xFF indicates that the enclosed community may
always be propagated over an EBGP boundary. A Hop Count value of
0xFF MUST NOT be decremented during propagation.
The length represents the total lengths of a given container in
octets.
2.2. Wide Community Atoms
Wide BGP communities will act on and hence need to encode some
distinct atoms of data. These are encoded as Sub-TLVs, where each
Sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+
| Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Type field contains a value of 0-254. The value 255 is
reserved for future use. The sub-TLV types are to be assigned and
maintained by IANA registry.
The length represents the total length of a given sub-TLV in octets.
The value field contains the sub-TLV value.
Supported format of the sub-TLVs can be:
Raszuk, et al. Expires January 14, 2013 [Page 6]
Internet-Draft wide-bgp-communities July 2012
- Type 1: 4 octets : Autonomous System number
- Type 2: 1..5 octets : IPv4 prefix (1 octet prefix length + prefix)
- Type 3: 1..17 octets : IPv6 prefix (1 octet prefix length + prefix)
- Type 4: 4 octets : Integer
- Type 5: variable : UTF-8 String
- Type 6: 4 octets : IEEE Floating Point Number
- Type 7: variable : Grouping Container (for logical AND)
- Type 8: 1 octet : Neighbor Class
The semantics of a given atom will depend on the context it is used
as defined by the containing wide community.
For consistent treatment, all AS numbers MUST be encoded as 4 octet
values. When encoding two octet ASes, the first two octets of this
four octet value MUST be filled with zeros.
Two special values are reserved for the Autonomous System atom:
0x00000000 - to indicate "No Autonomous Systems".
0xFFFFFFFF - to indicate "All Autonomous Systems".
The Grouping Container is intended for use for Wide Community
Targets. Targets typically have a "match any" behavior. When a
Grouping Container is present in a target, all contained atoms must
match for the community to be applied.
The Neighbor Class atom represents a classification of a BGP peering
session. This class currently can contain three values:
1 - Peer: This class is typically applied to sessions where a
transit-free relationship exists between two providers.
2 - Customer: This class is typically applied to sessions where
the remote end of the session is operated by a customer.
3 - Upstream: This class is typically applied to sessions where
the remote end of the session is operated by a network from which
you receive transit routes.
Raszuk, et al. Expires January 14, 2013 [Page 7]
Internet-Draft wide-bgp-communities July 2012
3. Container Type 1: Wide Community
The Wide BGP Community Type 1 container is of variable size and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registered/Local Community Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Community Target(s) TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Community Parameter(s) TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Wide BGP Community Type 1
3.1. Community Value
Community Value: 4 octets
The Wide BGP Community value indicates what set of actions a
router is requested to take upon reception of a route containing
this community. The semantics of this value depend on whether
this is a private/local community or registered.
3.2. Source AS Number
Source Autonomous System Number: 4 octets
The Autonomous System number which indicates the originator of
this Wide BGP Community.
When the Autonomous System is a two octet number the first two
octets of this 4 octet value MUST be filled with zeros.
3.3. Context AS Number
Context Autonomous System Number: 4 octets
The Autonomous System number that indicates the context of the
Registered/Local Value. When the value is a Registered Value (and
thus registered with IANA), this field MUST be 0.
Raszuk, et al. Expires January 14, 2013 [Page 8]
Internet-Draft wide-bgp-communities July 2012
When the wide community is locally registered, the Context
Autonomous System Number indicates the AS that defines the format
of this wide community for the given Local Value. (In other
words, value 1 will likely refer to different formats for AS 1 vs.
AS 2.)
3.4. Wide Community Target(s) TLV
Type: 1
The Wide Community Target(s) TLV has the same format as a Wide
Community atom.
Wide Community Targets define the matching criteria for the
community. A given wide community may have a number of targets that
it applies to. The semantics of these targets will vary on a per
community basis. Depending on the definition of the community,
targets may be optional.
The value field of the Wide Community Target(s) TLV is a series of
Wide Community Atom TLVs. The semantics of any given atom TLV MUST
be part of the definition of a given Wide Community.
Typically, Wide Community Targets consist of a series of atoms that
have "match any" semantics. Thus, if any given target matches per
the semantics of that atom for the community, the community is
considered to match and the action defined by the community should be
executed.
The Grouping Container atom permits a set of atoms with semantics
defined by the community to be nested. The Grouping Container atom
is considered to be a matching target if, and only if, all of its
contained atoms match per the semantics of the community.
If the semantics of a given atom is undefined for the community in
question, it MUST be ignored. If an atom with undefined semantics is
part of a Grouping Container, the entire container MUST be ignored.
When no targets are required by the definition of a given Wide
Community, the Wide Community Target TLV SHOULD NOT be encoded in the
community. Implementations MUST be prepared to accept a Wide
Community Target TLV with an empty value field.
3.5. Wide Community Parameter(s) TLV
Type: 2
The Wide Community Parameter(s) TLV has the same format as a Wide
Raszuk, et al. Expires January 14, 2013 [Page 9]
Internet-Draft wide-bgp-communities July 2012
Community atom.
A given wide community may have parameters which are used as inputs
for executing actions defined for that community. These parameters,
and any constraints implied by the parameters, MUST be defined by the
wide community definition. Parameters consist of an ordered set of
atom sub-TLVs. The semantics of any specific positional instance of
an atom MUST be defined by the wide community.
If it is the case that a paramter for a given community is of an
unexpected type, the community MUST be ignored.
If it is the case that there are too many or two few parameters for a
given community, the community MUST be ignored.
When no parameters are required by the definition of a given Wide
Community, the Wide Community Paramters TLV SHOULD NOT be encoded in
the community. Implementations MUST be prepared to accept a Wide
Community Parameter TLV with an empty value field.
3.6. Usage
The detailed interpretation of the targets or parameters SHALL be
provided when describing given community type in a separate document
or when locally defined by an operator.
4. Well Known Standard BGP Communities
According to RFC 1997, as well as IANA's Well-Known BGP Communities
registry, 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.
For the same reason, this document does not intended to obsolete the
currently defined and deployed BGP Extended Communities.
Raszuk, et al. Expires January 14, 2013 [Page 10]
Internet-Draft wide-bgp-communities July 2012
5. Operational considerations
Having two different ways to propagate locally assigned BGP
communities, one via the use of Standard BGP Communities and the
other one via the use of Wide BGP Communities, may seem to
potentially cause problems when considering propagation of
conflicting actions. However, even at present, an operator may
append Standard BGP Communities with conflicting information. It is
therefore recommended that any implementation, in supporting both
standard and Wide BGP communities, allow for their easy inbound and
outbound processing. The actual execution of all communities should
be treated as a union and, if supported by an implementation, their
execution permissions are to be a local configuration matter.
6. Example
6.1. Example Wide Community Definition
An operator wishes to locally define a Wide Community with the
semantics of permitting AS_PATH prepending with targets that include
AS numbers of peer ASes and peers who have been marked with a set of
defined "color" strings.
Target semantics:
Grouping containers MAY be used.
The Autonomous System Number atom refers to the target peer AS
Number.
The UTF-8 String atom refers to a peer "color". The values are
constrained to the strings "red", "green" or "blue".
The semantics of all other atoms are undefined for this community.
Parameter semantics:
The parameter TLV shall consist of exactly one integer value that
is constrained to have a value of 2..8.
Raszuk, et al. Expires January 14, 2013 [Page 11]
Internet-Draft wide-bgp-communities July 2012
6.2. Example Wide Community Encoding
AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as
"red" or to peers marked "blue" AND AS 1111.
Use Hop Count 0 to request the receiving router to not propagate
this wide community.
Locally community value (flag bit 0 = 0).
Do not decrement Hop Count field across confederation boundaries
(0)
Local community 1 for sample AS 64512.
Raszuk, et al. Expires January 14, 2013 [Page 12]
Internet-Draft wide-bgp-communities July 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: LOCAL PREPEND ACTION CATEGORY 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 64512 (0x0000FC00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target TLV (1)| Length: 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ASN (1) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 2424 (0x00000978) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ASN (1) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 8888 (0x000022B8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Str (5) | Length: 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer color "red" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Grp (7)| Length: 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Str (5) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer color "blue" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ASN (1) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ASN# 1111 (0x00000457) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (2) | Length: 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type INT (4) | Length: 1 | Prepend #: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Raszuk, et al. Expires January 14, 2013 [Page 13]
Internet-Draft wide-bgp-communities July 2012
7. Security considerations
All the security considerations for BGP Communities as well as for
BGP RFCs apply here.
8. IANA Considerations
This document defines a new BGP Path Attribute called Wide BGP
Community Attribute. For this new type IANA is to allocate a new
value in the corresponding registry:
Registry Name: BGP Path Attributes
This document makes the following assignments for the optional,
transitive Wide BGP Communities Attribute:
Name Type Value
---- ----------
Wide BGP Community Attribute TBA
This document requests IANA to define and maintain a new registry
named: "Wide BGP Communities Attribute Container Types".
The pool of: 0x0000-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 Wide BGP
Communities Attribute Types values:
Name Type Value
---- ----------
Reserved 0x0000
Type 1 0x0001
Types 2-1023 to be allocated using IETF Consensus
Types 1024-64511 to be allocated first come, first served
Types 64512-65534 are reserved for experimental use
Reserved 0xFFFF
This document requests IANA to define and maintain a new registry
named: "Wide BGP Communities sub-TLV types". The pool of 0x0000-
0xFFFF has been defined for its allocations. This document defines
type 1. Types 2-1024 are to be allocated using an IETF Consensus
policy. Types 1024-64511 are to be allocated on a first come, first
served basis. Types 64512-65534 are to be reserved for experimental
Raszuk, et al. Expires January 14, 2013 [Page 14]
Internet-Draft wide-bgp-communities July 2012
use.
This document makes the following assignments for the Wide BGP
Communities sub-TLV type values:
Name Type Value
---- ----------
Reserved 0x00
AS Number 0x01
IPv4 Prefix 0x02
IPv6 Prefix 0x03
Integer 0x04
UTF-8 string 0x05
IEEE Floating Point Value 0x06
Container Group 0x07
Reserved 0xFF
9. Change History
Changes from -02 to -03:
Removed C and R named bit fields originally from -00.
Rename Target AS field to Context AS.
Make Integer Atom a fixed 4 octets in length.
Add Neighbor Class Atom
Rename TTL to Hop Count
Changes from -01 to -02:
The Type field has been expanded to 2 octets.
The Length field has been moved to the common header.
Changed format to use TLVs.
Added atom TLV to define well defined syntactic items.
Added TLVs to distinguish targets from parameters.
Various editorial changes to language.
Raszuk, et al. Expires January 14, 2013 [Page 15]
Internet-Draft wide-bgp-communities July 2012
10. Contributors
The following people contributed significantly to the content of the
document:
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
11. Acknowledgments
This document owes draft-lange-flexible-bgp-communities a debt for
the inspiration of many features contained herein.
The authors would like to thank Enke Chen, Pedro Marques and Alton Lo
for their valuable input.
12. References
Raszuk, et al. Expires January 14, 2013 [Page 16]
Internet-Draft wide-bgp-communities July 2012
12.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.
12.2. Informative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[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 (editor)
NTT MCL Inc.
101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401
US
Email: robert@raszuk.net
Jeffrey Haas (editor)
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
US
Email: jhaas@juniper.net
Raszuk, et al. Expires January 14, 2013 [Page 17]
Internet-Draft wide-bgp-communities July 2012
Shane Amante
Level 3 Communications, LLC
1025 Eldorado Blvd
Broomfield, CO 80021
US
Email: shane@level3.net
Richard A Steenbergen
nLayer Communications, Inc.
209 W Jackson Blvd
Chicago, IL 60606
US
Email: ras@nlayer.net
Bruno Decraene
France Telecom
38-40 rue du General Leclerc
Issi Moulineaux cedex 9 92794
France
Email: bruno.decraene@orange-ftgroup.com
Paul Jakma
University of Glasgow
School of Computing Science
Sir Alwyn Williams Building
University of Glasgow
Glasgow G12 8QQ
UK
Email: paulj@dcs.gla.ac.uk
Raszuk, et al. Expires January 14, 2013 [Page 18]