draft-ietf-grow-collection-communities-03.txt   draft-ietf-grow-collection-communities-04.txt 
INTERNET-DRAFT D. Meyer INTERNET-DRAFT D. Meyer
draft-ietf-grow-collection-communities-03.txt draft-ietf-grow-collection-communities-04.txt
Category Best Current Practice Category Best Current Practice
Expires: September 2004 March 2004 Expires: September 2004 March 2004
BGP Communities for Data Collection BGP Communities for Data Collection
<draft-ietf-grow-collection-communities-03.txt> <draft-ietf-grow-collection-communities-04.txt>
Status of this Document Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This document is a product of the GROW WG. Comments should be This document is a product of the GROW WG. Comments should be
addressed to the authors, or the mailing list at grow@lists.uoregon.edu. addressed to the authors, or the mailing list at
grow@lists.uoregon.edu.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
BGP communities (RFC 1997) are used by service providers for many BGP communities (RFC 1997) 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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
implement this scheme (as there is a large amount of existing data as implement this scheme (as there is a large amount of existing data as
well as many legacy peerings). well as many legacy peerings).
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
provides both the definition of terms used as well as the semantics provides both the definition of terms used as well as the semantics
of the communities used for BGP data collection, and section 3 of the communities used for BGP data collection, and section 3
defines the corresponding encodings for RFC 1997 [RFC1997] defines the corresponding encodings for RFC 1997 [RFC1997]
communities. Finally, section 4 defines the encodings for use with communities. Finally, section 4 defines the encodings for use with
extended communities [EXTCOMM]. extended communities [EXTCOMM].
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Definitions 2. Definitions
In this section, we define the terms used and the categories of In this section, we define the terms used and the categories of
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
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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 | Sub-Type | Global Administrator | | 0x00 | Sub-Type | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator | | Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The two-octet AS specific extended community attribute encodes the The two-octet AS specific extended community attribute encodes the
service provider's two octet Autonomous System number (as assigned by service provider's two octet Autonomous System number (as assigned by
an Internet Routing Registry) in the Global Administrator field, and an Regional Internet Registry, or RIR) in the Global Administrator
the Local Administrator field may encode any information. field, and the Local Administrator 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:4338 For example, the extended community encoding for 10876:4338
(representing a terrestrial national route in AS 10876 from the Fiji (representing a terrestrial national route in AS 10876 from the Fiji
Islands) would be: Islands) would be:
skipping to change at page 13, line 9 skipping to change at page 13, line 9
This document assigns a new Sub-Type for the AS specific extended This document assigns a new Sub-Type for the AS specific extended
community type. In particular, the IANA should assign Sub-type 0x05, community type. In particular, the IANA should assign Sub-type 0x05,
using the "First Come First Served" policy defined in RFC 2434 using the "First Come First Served" policy defined in RFC 2434
[RFC2434], for the Sub-Type defined in Section 4. This corresponds to [RFC2434], for the Sub-Type defined in Section 4. This corresponds to
a Type Field value of 0x0005. a Type Field value of 0x0005.
8. References 8. References
8.1. Normative References 8.1. Normative References
[EXTCOMM] Sangali, S., D. Tappan and Y. Rekhter, "BGP Extended Communities [EXTCOMM] Sangali, S., D. Tappan and Y. Rekhter, "BGP Extended
Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, Communities Attribute", draft-ietf-idr-bgp-ext-communities-06.txt,
Work in Progress. Work in progress.
[ISO-3166-2] http://www.iso.org/iso/en/prods-services/iso3166ma/index.html [ISO-3166-2] http://www.iso.org/iso/en/prods-services/iso3166ma/index.html
[RIS-ISO-3166] ftp://ftp.ripe.net/iso3166-countrycodes.txt [RIS-ISO-3166] ftp://ftp.ripe.net/iso3166-countrycodes.txt
[RFC1771] Rekhter, Y., and T. Li (Editors), "A Border [RFC1771] Rekhter, Y. and T. Li (Editors), "A Border
Gateway Protocol (BGP-4)", RFC 1771, March, Gateway Protocol (BGP-4)", RFC 1771, March 1995.
1995.
[RFC1997] Chandra, R. and P. Traina, "BGP Communities [RFC1997] Chandra, R. and P. Traina, "BGP Communities
Attribute", RFC 1997, August, 1996. Attribute", RFC 1997, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
8.2. Informative References 8.2. Informative References
[HUSTON] Huston, G., "Interconnection, Peering, and Settlements", [HUSTON] Huston, G., "Interconnection, Peering, and Settlements",
http://www.isoc.org/inet99/proceedings/1e/1e_1.htm http://www.isoc.org/inet99/proceedings/1e/1e_1.htm
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March,
1997.
[RFC2026] Bradner, S., "The Internet Standards Process --
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", BCP 11,
2028/BCP 11, October, 1996. RFC 2028, 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. BCP 26, RFC 2434, October 1998.
[RFC3258] Hardie, T., "Distributing Authoritative Name [RFC3258] Hardie, T., "Distributing Authoritative Name
Servers via Shared Unicast Addresses", RFC 3258, Servers via Shared Unicast Addresses", RFC 3258,
April, 2002. April 2002.
[RIS] "Routing Information Service", http://www.ripe.net/ris [RIS] "Routing Information Service", http://www.ripe.net/ris
[ROUTEVIEWS] "The Routeviews Project", http://www.routeviews.org [ROUTEVIEWS] "The Routeviews Project", http://www.routeviews.org
[VPLS] Kompella, K., et al., "Virtual Private LAN
[VPLS] Kompella, K., et. al., "Virtual Private LAN Service", draft-ietf-l2vpn-vpls-bgp-01.txt,
Service", draft-ietf-l2vpn-vpls-bgp-00.txt,
Work in Progress. Work in Progress.
[WANG] Wang, F. and L. Gao, "Inferring and Characterizing [WANG] Wang, F. and L. Gao, "Inferring and Characterizing
Internet Routing Policies", ACM SIGCOMM Internet Internet Routing Policies", ACM SIGCOMM Internet
Measurement Conference 2003. Measurement Conference 2003.
9. Author's Addresses 9. Author's Addresses
D. Meyer David Meyer
EMail: dmm@1-4-5.net
Email: dmm@1-4-5.net
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
 End of changes. 

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