--- 1/draft-ietf-grow-collection-communities-03.txt 2006-02-04 23:23:57.000000000 +0100 +++ 2/draft-ietf-grow-collection-communities-04.txt 2006-02-04 23:23:57.000000000 +0100 @@ -1,42 +1,43 @@ INTERNET-DRAFT D. Meyer -draft-ietf-grow-collection-communities-03.txt +draft-ietf-grow-collection-communities-04.txt Category Best Current Practice Expires: September 2004 March 2004 BGP Communities for Data Collection - + -Status of this Document +Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + http://www.ietf.org/1id-abstracts.html 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 - 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 (C) The Internet Society (2004). All Rights Reserved. Abstract BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the @@ -105,23 +106,24 @@ implement this scheme (as there is a large amount of existing data as well as many legacy peerings). The remainder of this document is organized as follows. Section 2 provides both the definition of terms used as well as the semantics of the communities used for BGP data collection, and section 3 defines the corresponding encodings for RFC 1997 [RFC1997] communities. Finally, section 4 defines the encodings for use with 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 - 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 In this section, we define the terms used and the categories of routes that may be tagged with communities. This tagging is often referred to coloring, and we refer to a route's "color" as its community value. The categories defined here are loosely modeled on those described in [WANG] and [HUSTON]. 2.1. Peers and Peering @@ -316,22 +318,22 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The two-octet AS specific extended community attribute encodes the service provider's two octet Autonomous System number (as assigned by - an Internet Routing Registry) in the Global Administrator field, and - the Local Administrator field may encode any information. + an Regional Internet Registry, or RIR) in the Global Administrator + field, and the Local Administrator field may encode any information. This document assigns Sub-Type 0x05 for BGP data collection, and specifies that the field, as defined in section 3.1, is carried in the low order octets of the Local Administrator field. The two high order octets of the Local Administrator field are reserved, and are set to 0x00 when sending and ignored upon receipt. For example, the extended community encoding for 10876:4338 (representing a terrestrial national route in AS 10876 from the Fiji Islands) would be: @@ -410,76 +412,70 @@ This document assigns a new Sub-Type for the AS specific extended community type. In particular, the IANA should assign Sub-type 0x05, using the "First Come First Served" policy defined in RFC 2434 [RFC2434], for the Sub-Type defined in Section 4. This corresponds to a Type Field value of 0x0005. 8. References 8.1. Normative References - [EXTCOMM] Sangali, S., D. Tappan and Y. Rekhter, "BGP Extended Communities - Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, - Work in Progress. + [EXTCOMM] Sangali, S., D. Tappan and Y. Rekhter, "BGP Extended + Communities Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, + Work in progress. [ISO-3166-2] http://www.iso.org/iso/en/prods-services/iso3166ma/index.html [RIS-ISO-3166] ftp://ftp.ripe.net/iso3166-countrycodes.txt - [RFC1771] Rekhter, Y., and T. Li (Editors), "A Border - Gateway Protocol (BGP-4)", RFC 1771, March, - 1995. + [RFC1771] Rekhter, Y. and T. Li (Editors), "A Border + Gateway Protocol (BGP-4)", RFC 1771, March 1995. [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 [HUSTON] Huston, G., "Interconnection, Peering, and Settlements", 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 - Involved in the IETF Standards Process", RFC - 2028/BCP 11, October, 1996. + Involved in the IETF Standards Process", BCP 11, + RFC 2028, October 1996. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 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 Servers via Shared Unicast Addresses", RFC 3258, - April, 2002. + April 2002. [RIS] "Routing Information Service", http://www.ripe.net/ris [ROUTEVIEWS] "The Routeviews Project", http://www.routeviews.org - - [VPLS] Kompella, K., et. al., "Virtual Private LAN - Service", draft-ietf-l2vpn-vpls-bgp-00.txt, + [VPLS] Kompella, K., et al., "Virtual Private LAN + Service", draft-ietf-l2vpn-vpls-bgp-01.txt, Work in Progress. [WANG] Wang, F. and L. Gao, "Inferring and Characterizing Internet Routing Policies", ACM SIGCOMM Internet Measurement Conference 2003. 9. Author's Addresses - D. Meyer - - Email: dmm@1-4-5.net + David Meyer + EMail: dmm@1-4-5.net 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published