draft-ietf-grow-collection-communities-00.txt   draft-ietf-grow-collection-communities-01.txt 
INTERNET-DRAFT D. Meyer INTERNET-DRAFT D. Meyer
draft-ietf-grow-collection-communities-00.txt draft-ietf-grow-collection-communities-01.txt
Category Best Current Practice Category Best Current Practice
Expires: June 2004 December 2003 Expires: June 2004 December 2003
BGP Communities for Data Collection BGP Communities for Data Collection
<draft-ietf-grow-collection-communities-00.txt> <draft-ietf-grow-collection-communities-01.txt>
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2.2. Customer Routes . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Customer Routes . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Peer Routes . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Peer Routes . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Internal Routes . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Internal Routes . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Internal More Specific Routes . . . . . . . . . . . . . . . 5 2.5. Internal More Specific Routes . . . . . . . . . . . . . . . 5
2.6. Special Purpose Routes. . . . . . . . . . . . . . . . . . . 6 2.6. Special Purpose Routes. . . . . . . . . . . . . . . . . . . 6
2.7. Upstream Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Upstream Routes . . . . . . . . . . . . . . . . . . . . . . 6
2.8. National Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.8. National Routes . . . . . . . . . . . . . . . . . . . . . . 6
2.9. Regional Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.9. Regional Routes . . . . . . . . . . . . . . . . . . . . . . 6
3. RFC 1997 Community Encoding and Values . . . . . . . . . . . . 7 3. RFC 1997 Community Encoding and Values . . . . . . . . . . . . 7
3.1. Community Values for BGP Data Collection. . . . . . . . . . 7 3.1. Community Values for BGP Data Collection. . . . . . . . . . 7
4. Extended Communities . . . . . . . . . . . . . . . . . . . . . 8 4. Extended Communities . . . . . . . . . . . . . . . . . . . . . 9
4.1. Four-octet AS specific extended communities . . . . . . . . 10
5. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 10 5. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7.1. Total Path Attribute Length . . . . . . . . . . . . . . . . 11 7.1. Total Path Attribute Length . . . . . . . . . . . . . . . . 12
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References. . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References. . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References. . . . . . . . . . . . . . . . . . . 12 9.2. Informative References. . . . . . . . . . . . . . . . . . . 13
10. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 13 10. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 14
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
BGP communities [RFC1997] are used by service providers for many BGP communities [RFC1997] are used by service providers for many
purposes, including tagging of customer, peer, and geographically purposes, including tagging of customer, peer, and geographically
originated routes. Such tagging is typically used to control the originated routes. Such tagging is typically used to control the
scope of redistribution of routes within a providers network, and to scope of redistribution of routes within a providers network, and to
it's customers and peers. Communities are also used for a wide it's customers and peers. Communities are also used for a wide
variety of other applications, such as allowing customers to set variety of other applications, such as allowing customers to set
attributes such as LOCAL_PREF [RFC1771] by sending appropriate attributes such as LOCAL_PREF [RFC1771] by sending appropriate
skipping to change at page 5, line 10 skipping to change at page 5, line 10
routes that may be tagged with communities. This tagging is often routes that may be tagged with communities. This tagging is often
referred to coloring, and we refer to a route's "color" as its referred to coloring, and we refer to a route's "color" as its
community value. The categories defined here are loosely modeled on community value. The categories defined here are loosely modeled on
those described in [WANG] and [HUSTON]. those described in [WANG] and [HUSTON].
2.1. Peers and Peering 2.1. Peers and Peering
Consider two network service providers, A and B. Service providers A Consider two network service providers, A and B. Service providers A
and B are defined to be peers when (i). A and B exchange routes via and B are defined to be peers when (i). A and B exchange routes via
BGP, and (ii). traffic exchange between A and B is settlement-free. BGP, and (ii). traffic exchange between A and B is settlement-free.
This arrangement is also known as "peering". Peers typically exchange This arrangement is also typically known as "peering". Peers
only their respective customer routes (see "Customer Routes" below), typically exchange only their respective customer routes (see
and hence exchange only their respective customer traffic. See "Customer Routes" below), and hence exchange only their respective
[HUSTON] for a more in-depth discussion of the business models customer traffic. See [HUSTON] for a more in-depth discussion of the
surrounding peers and peering. business models surrounding peers and peering.
2.2. Customer Routes 2.2. Customer Routes
Customer routes are those routes which are heard from a customer via Customer routes are those routes which are heard from a customer via
BGP and are propagated to peers and other customers. Note that a BGP and are propagated to peers and other customers. Note that a
customer can be an enterprise or another network service provider. customer can be an enterprise or another network service provider.
These routes are sometimes called client routes [HUSTON]. These routes are sometimes called client routes [HUSTON].
2.3. Peer Routes 2.3. Peer Routes
skipping to change at page 8, line 7 skipping to change at page 8, line 7
anticipated that a service provider's internal community values will anticipated that a service provider's internal community values will
be converted to these standard values for output to a route be converted to these standard values for output to a route
collector. collector.
This document follows the best current practice of using the basic This document follows the best current practice of using the basic
format <AS>:<Value>. The values for the route categories are format <AS>:<Value>. The values for the route categories are
described in the following table: described in the following table:
Category Value Category Value
=============================================================== ===============================================================
Customer Routes <AS>:64500 Reserved <AS>:0000000000000000
Peer Routes <AS>:64510 Customer Routes <AS>:0000000000000001
Internal Routes <AS>:64520 Peer Routes <AS>:0000000000000010
Internal More Specific Routes <AS>:64530 Internal Routes <AS>:0000000000000011
Special Purpose Routes <AS>:64540 Internal More Specific Routes <AS>:0000000000000100
Upstream Routes <AS>:64550 Special Purpose Routes <AS>:0000000000000101
Reserved <AS>:64551-65535 Upstream Routes <AS>:0000000000000110
National and Regional Routes Reserved <AS>:0000000000000110-
Africa (AF) <AS>:0<CC> <AS>:0000111111111111
Asia/Australia/Pacific (AP) <AS>:1<CC> National and Regional Routes <AS>:0001000000000000-
Antarctica (AQ) <AS>:2<CC> <AS>:1111111111111111
Europe (EU) <AS>:3<CC> Africa (AF) <AS>:0001<X><CC>
Latin America/Caribbean islands (LAC) <AS>:4<CC> Oceania (OC) <AS>:0010<X><CC>
North America (NA) <AS>:5<CC> Asia (AS) <AS>:0011<X><CC>
Antarctica (AQ) <AS>:0100<X><CC>
Europe (EU) <AS>:0101<X><CC>
Latin America/Caribbean islands (LAC) <AS>:0110<X><CC>
North America (NA) <AS>:0111<X><CC>
Reserved <AS>:1000000000000000-
<AS>:1111111111111111
In the above table, the <CC> field contains the ISO-3166-2 encoding In the above table,
of the country code [ISO-3166-2,RIS-ISO-3166], which is right-
justified (i.e., left zero-padded) in the <CC> field. For example, <AS> is the 16-bit AS
the community 10876:10242 would represent a national route in AS <R> is the 5-bit Region
10876 from the Fiji Islands, since the Fiji Islands are in the AP <X> is 1-bit satellite link indication (1 if satellite link, 0 otherwise)
region (Region Code 1) and have ISO-3166-2 numeric country code 242. <CC> is the 10-bit ISO-3166-2 country code
That is:
that is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2A7C | 0x2802 | | <AS> | <R> |X| <CC> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For example, the encoding for a national route over a terrestrial
link in AS 10876 from the Fiji Islands would be:
<AS> = 10876 = 0x2A7B
<R> = OC = 0010
<X> = 0x0
<CC> = Fiji Islands Country Code = 242 = 0011110010
so that the low order 16 bits look like 001000011110010 = 0x10F2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2A7C | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that a configuration language might have allow the specification
of this community as 10876:4338 (0x1F2 == 4338 decimal).
Finally, note that these categories are not intended to be mutually Finally, note that these categories are not intended to be mutually
exclusive, and multiple communities can be attached where exclusive, and multiple communities can be attached where
appropriate. appropriate.
4. Extended Communities 4. Extended Communities
In some cases, the encoding described in section 3.1 may clash with a In some cases, the encoding described in section 3.1 may clash with a
service provider's existing community assignments. Extended service provider's existing community assignments. Extended
communities [EXTCOMM] provide a convenient mechanism that can be used communities [EXTCOMM] provide a convenient mechanism that can be used
to avoid such clashes. to avoid such clashes.
skipping to change at page 9, line 36 skipping to change at page 10, line 15
service provider's two octet Autonomous System number assigned by service provider's two octet Autonomous System number assigned by
IANA in the Global Administrator field, and the Local Administrator IANA in the Global Administrator field, and the Local Administrator
field may encode any information. field may encode any information.
This document assigns Sub-Type 0x05 for BGP data collection, and This document assigns Sub-Type 0x05 for BGP data collection, and
specifies that the <Value> field, as defined in section 3.1, is specifies that the <Value> field, as defined in section 3.1, is
carried in the low order octets of the Local Administrator field. The carried in the low order octets of the Local Administrator field. The
two high order octets of the Local Administrator field are reserved, two high order octets of the Local Administrator field are reserved,
and are set to 0x00 when sending and ignored upon receipt. and are set to 0x00 when sending and ignored upon receipt.
For example, the extended community encoding for 10876:10242 For example, the extended community encoding for 10876:4338
(representing a national route in AS 10876 from the Fiji Islands) (representing a terrestrial national route in AS 10876 from the Fiji
would be: Islands) would be:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x05 | 0x2A7C | | 0x00 | 0x05 | 0x2A7C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x2802 | | 0x00 | 0x00 | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1. Four-octet AS specific extended communities
The four-octet AS specific extended 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x05 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case, the 4 octet Global Administrator sub-field contains a
4-octets Autonomous System number assigned by the IANA.
5. Intellectual Property 5. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [RFC2028]. standards-related documentation can be found in BCP-11 [RFC2028].
skipping to change at page 10, line 29 skipping to change at page 11, line 23
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
6. Acknowledgments 6. Acknowledgments
The community encoding described in this document germinated from an
interesting suggestion from Akira Kato at WIDE. In particular, the
idea would be to use the collection community values to select paths
that would result in (hopefully) more efficient access to various
services. For example, in the case of RFC 3258 [RFC3258] based DNS
anycast service, BGP routers may see multiple paths to the same
prefix, and others might be coming from the same origin with
different paths, but others might be from different region/country
(with the same origin AS).
Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay
Gill, John Heasley, Geoff Huston, Steve Huter, Olivier Marce, Ryan Gill, John Heasley, Geoff Huston, Steve Huter, Olivier Marce, Ryan
McDowell, Rob Rockell, Rob Thomas, and Patrick Verkaik all made many McDowell, Rob Rockell, Rob Thomas, and Patrick Verkaik all made many
insightful comments on early versions of this draft. Henk Uijterwaal insightful comments on early versions of this draft. Henk Uijterwaal
suggested the use of the ISO-3166-2 country codes. suggested the use of the ISO-3166-2 country codes.
7. Security Considerations 7. Security Considerations
While this document introduces no additional security considerations While this document introduces no additional security considerations
into the BGP protocol, the information contained in the communities into the BGP protocol, the information contained in the communities
skipping to change at page 13, line 12 skipping to change at page 14, line 12
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026/BCP 9, October, 1996. Revision 3", RFC 2026/BCP 9, October, 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations [RFC2028] Hovey, R. and S. Bradner, "The Organizations
Involved in the IETF Standards Process", RFC Involved in the IETF Standards Process", RFC
2028/BCP 11, October, 1996. 2028/BCP 11, October, 1996.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
RFC 2434/BCP 26, October 1998. RFC 2434/BCP 26, October 1998.
[RFC3258] Hardie, T., "Distributing Authoritative Name
Servers via Shared Unicast Addresses", RFC 3258,
April, 2002.
10. Author's Addresses 10. Author's Addresses
D. Meyer D. Meyer
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/