IDR | J. Heitz |
Internet-Draft | K. Patel |
Intended status: Standards Track | Cisco |
Expires: January 6, 2017 | J. Snijders |
NTT | |
I. Bagdonas | |
Equinix | |
July 5, 2016 |
Large BGP Community
draft-heitz-idr-large-community-00
A new type of BGP community attribute that contains communities that each hold a 4-octet AS number and a 6-octet opaque field is defined.
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 [RFC2119].
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 6, 2017.
Copyright (c) 2016 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.
A BGP Community attribute is defined that encodes 12 byte communities, suitable for 4-Octet Autonomous System Numbers that require a 6-Octet Local Administrator field.
The 2-octet AS Specific Extended Community defined in [RFC4360] has been widely used. 4-octet AS numbers as defined by [RFC4893] are unable to make use of this popular extended community. Subsequently, [RFC5668] defined a 4-octet AS Specific Extended community. However, to make room for the extra 2 octets of AS number, the Local Administrator field was shrunk from 4 octets to 2. This document defines a community to extend that to 6 octets.
To ensure rapid and smooth adoption of the new community attribute, it must be as similar to the extended community as possible, only bigger.
The Large Community Attribute is a transitive optional BGP attribute, with the Type Code (suggested 41) to be assigned by IANA. The attribute consists of a set of "Large Communities". All routes with the Large Community attribute belong to the communities listed in the attribute.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| T | Type | Sub-Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each Large Community is encoded as a 12-octet quantity, as follows:
The fields are as shown below:
The Transitivity field is only a hint to BGP speakers that do not implement or understand the specific community. In some cases it makes sense to send a community across one boundary but not the next. An example is the Link Bandwidth Extended Community.
The Transitivity field is not implicitly associated with the Type and Sub-Type fields the way they are in Extended Communities. The Transitivity field should be set by the originator based upon individual circumstances at the originator
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| T | 0| Sub-Type | Local Administrator 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a Large Community type with a Value field comprising 10 octets.
The definition of each sub-type should specify how to set the T field. The Type field is 0. The Sub-Type is to be assigned by IANA for individual functions.
The Value field consists of 2 sub-fields:
The textual representation of the 4-Octet AS Specific Large Community is A:B:C, where A is the Global Administrator, B is the Local Administrator 1 and C is the Local Administrator 2. A ranges from 0 to 4294967295. B ranges from 0 to 4294967295. C ranges from 0 to 65535. A, B and C are plain decimal numbers without leading zeroes. Each number must appear, even if it is 0. For example, "0:1:2" cannot be written as ":1:2".
Any 2-octet AS Specific Extended Community [RFC4360] can be converted into a 4-octet AS Specific Large Community by copying:
Notice that the Global Administrator and the Local Administrator fields in the Large community are in the reverse order compared to those in the Extended Community. This is done for better octet alignment.
If a community contains an Autonomous System Number less than 65536 and a Local Administrator 2 field of zero, then it can be represented either as a 4-Octet AS Specific Large Community or a 2-Octet AS Specific Extended Community. These communities would be treated as different, even though they hold the same information. To prevent such inconsistencies, such communities SHOULD be encoded as a 2-Octet Specific Extended Community.
Similarly, if a community contains an Autonomous System Number greater than 65535 and a Local Administrator field less than 65536, then it SHOULD be encoded as a 4-Octet AS Specific Extended Community as per [RFC5668].
The AS portion of BGP Communities described in [RFC1997] is too small to fit a 4-octet ASN. [I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines an Extended Community sub-type to perform the same function with a 4-octet ASN. Large Communities will provide the same functionality, but provide an extra 4 octets of Local Administrator space.
TBD
IANA is requested to assign a BGP path attribute value for the Large community attribute.
IANA is requested to create and maintain a registry for the Type field of the Large Community. This document reserves the Type value 0 for the 4-Octet AS Specific Large Community.
IANA is requested to create and maintain a registry for the Sub-Type field of the 4-Octet AS Specific Large Community. The initial values in the registry should be the same as those in the registry for the 2-octet AS Specific Extended Community. These values are reproduced as follows:
As the generic sub-type defined in [I-D.ietf-idr-as4octet-extcomm-generic-subtype] is 4 and clashes with the value for the Link Bandwidth, IANA is requested to assign a new value.
Thanks to Russ White, Acee Lindem and Shyam Sethuram for insightful review and comments.
[I-D.ietf-idr-as4octet-extcomm-generic-subtype] | Rao, D., Mohapatra, P. and J. Haas, "Generic Subtype for BGP Four-octet AS specific extended community", Internet-Draft draft-ietf-idr-as4octet-extcomm-generic-subtype-08, June 2015. |
[RFC1997] | Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC4360] | Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006. |
[RFC4893] | Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007. |
[RFC5668] | Rekhter, Y., Sangli, S. and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, October 2009. |