| IDR | J. Heitz |
| Internet-Draft | A. Sajassi |
| Updates: 4684 (if approved) | Cisco |
| Intended status: Standards Track | I. Bagdonas |
| Expires: September 6, 2018 | Equinix |
| March 5, 2018 |
BGP Extra Extended Community
draft-heitz-idr-extra-extended-community-00
Auto-derived identifiers are used by applications to enable zero configuration features. Such identifiers are often a combination of primitive identifiers and are thus longer. In addition, existing identifiers have grown longer. IP addresses have grown from 4 octets to 16. AS numbers have grown from 2 octets to 4. In order to accommodate such longer identifiers in BGP extended communities, this document defines a new BGP path attribute, the Extra Extended Communities attribute. It is similar to the Extended Community, but is 24 octets long. Communities are mostly used within ASes under a single administration or between neighboring ASes. Limiting the spread of communities beyond their intended reach and polluting the internet at large is complex and error prone. To simplify this, enhanced transitivity options are provided.
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 https://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 September 6, 2018.
Copyright (c) 2018 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 (https://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 Extended Community attribute is defined that encodes 24 octet communities. It is similar to the Extended Communities attribute defined in [RFC4360], but larger. To simplify the IANA registries, the transitivity of a Extra Extended Community is not part of the IANA registered type. Any type can be encoded with any transitivity. BGP autonomous system (AS) relationships have become more complex. Several contiguous ASes may be under a common administration. A transitivity is defined that allows a XXC to be sent among these ASes only. Some XXCs may be required to be transferred only between neighboring ASes, even though they are under a different administration. A transitivity type to allow this is defined. Up to now, the range of ASes among which a community is distributed is enforced by routing policies. These policies are sometimes executed in the receiving AS, not under the control of the sending AS. The enhanced transitivity options offerend in this document will simplify policies that are used to distribute communities.
The Extra Extended Communities Attribute is a transitive optional BGP attribute, with the Type Code [to be assigned by IANA]. The attribute consists of a set of "Extra Extended Communities" (XXC).
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | Type | Sub-Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + | | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each XXC is encoded as a 24-octet quantity, as follows:
The fields are as shown below:
The transitivity field determines how BGP speakers transfer the XXC across real Autonomous System (AS) boundaries. The XXC is always transitive between Member-ASes in an AS confederation [RFC5065]. The values are:
To be not transitive means that a receiving BGP speaker MUST silently discard the community by default and a sending speaker MUST not send the community by default. A speaker MAY send or receive a non-transitive XXC if explicitly configured to do so..
A single administration may own a multitude of contiguous ASes. XXCs with transitivity types 2 and 3 are transitive between these ASes. If a BGP neighbor session is to a speaker in the same administration, it needs a booelan configuration to indicate that. Without this configuration, an EBGP BGP neighbor is assumed to be under a different administration.
A BGP speaker that receives a XXC with transitivity 3 from a neighbor in an AS under a different administration MUST change the transitivity field of the XXC to 2. As an exception, a route server as defined in [RFC7947] SHOULD NOT change the transitivity field.
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. The transitivity is not assigned by IANA.
BGP speakers that do not implement Extra Extended Communities will transfer XXCs even though they may not be transitive across their AS boundaries. To prevent this, a BGP capability as defined in [RFC5492] is required. The length of the capability is 0. A BGP speaker MUST NOT by default send a XXC, the transitivity of which is not 0, to a speaker that has not sent the Extra Extended Community Capability in its OPEN message. A BGP speaker MUST withdraw a route from a neighbor if that neighbor does not advertise this capability and the route contanis an XXC unless it is known that announcing the route will cause no adverse effects. An example of where no adverse effects occur is when the neighbor is a route reflector that does not forward traffic and all the route reflector clients support XXC.
[RFC4684] defines Constrained Route Distribution. That document is updated as follows:
The maximum prefix size is modified from 96 bits to 224 bits.
Route targets can be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator. Route Target prefixes can be aggregated. However if done so, then Route Target Type, Sub-Type and the Global Administrator Route Target fields MUST NOT be aggregated.
The Extra Extended Community capability in combination with the capability of the Constrained Route Distribution Address Family indicates the ability to use the longer RT Constraint prefix described herein.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 0 | Sub-Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Global Administrator | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 1 | Sub-Type | Global Administrator : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Global Administrator (cont.) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Local Administrator | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 1. The Sub-Type is to be assigned by IANA for individual functions.
The Value field consists of 2 sub-fields:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 2 | Sub-Type | Global Administrator : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Global Administrator (cont.) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Administrator | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 2. The Sub-Type is to be assigned by IANA for individual functions.
The Value field consists of 2 sub-fields:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 6 | Sub-Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + | | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a Extra Extended Community type with a Value field comprising 22 octets.
The Type field is 6. The Sub-Type is to be assigned by IANA for individual functions. Three functions are defined in this document.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 6 | 2 | GA : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GA (Cont.) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Zero | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ESI + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ES-Import Route Target as specified in [RFC7432] Sec. 7.6 limits the ESI to 6 octets. Thus it cannot be automatically derived for all ESI types. This ES-Import RT-XXC allows the use of the full 10 octets of ESI.
The Type field is 6. The Sub-Type is 2. The fields are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 6 | 4 | GA : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GA (Cont.) | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ESI + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EVI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ESI-EVI Route Target is used in EVPN route types 7 and 8 to filter routes by both ESI and Ethernet Tag ID. More details are in [I-D.ietf-bess-evpn-igmp-mld-proxy].
The Type field is 6. The Sub-Type is 4. The fields are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | 6 | 6 | GA : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GA (Cont.) |A| Space | Domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | Service-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This EVPN Overlay Route Target Extra Extended Community type is used to filter routes based upon the identifier used in the specified overlay protocol. More details are in [I-D.ietf-bess-evpn-overlay].
The Type field is 6. The Sub-Type is 6. The fields are as follows:
Auto-derivation of EVPN Route Targets is described in [RFC7432] Sec. 7.10.1. Because of the limited size of Route Targets using Extended Communities, the auto-derivation is limited to using the 12 bit VLAN ID. With the larger size of the RT-XXC, the complete 32 bits of the Ethernet Tag ID can be used.
The EVPN RT-XXC can use all the RT-XXC types: AS-Specific, IPv4-Address-Specific and IPv6-Address-Specific. In each case, the Ethernet Tag ID is placed into the least significant octets of the Local Administrator field. The remaining higher order bits of the Local Administrator field are used as a discriminator as follows. The numerical value of the Ethernet Tag ID may be the same as a value that a different protocol may be using to create RT-XXCs of the same Type and Sub-Type. EVPN needs to use a value of the discriminator such as not to cause value collisions with other protocols that are auto-deriving route targets in the same Global Administrator.
A BGP Extra Extended Communities attribute SHALL be considered malformed if the length of the BGP Extra Extended Communities Attribute value, expressed in octets, is not a non-zero multiple of 24. The error SHALL be handled using the approach of "treat-as-withdraw" as described in Section 2 of [RFC7606].
The order in which the XXCs appear in the XXC attribute is not significant. It is not an error for a BGP speaker to propagate a set of XXCs in a different order than in which they were received.
A BGP speaker SHOULD NOT send a duplicate XXC. However, this is not an error, but merely suboptimal. The duplication of a XXC has no meaning. A receiver of a duplicate XXC SHOULD silently discard the duplicate. The duplication of a XXC cannot be used to compound its effect. For example if one XXC causes the local preference to be incremented by 5, the presence of two of the same XXC will not increment the LP by 10. OTOH, if one XXC increments the LP by 5 and a different XXC increments it by 10, then the combination will cause an increment of 15.
A BGP speaker MAY send XXCs that are duplictes except for the transitivity field. Receipt of such duplicates MUST be treated as receipt of distinct XXCs. While it makes little sense for a BGP speaker to originate such duplicates, this duplication may occur when XXCs from different received routes are aggregated. In any case, the same kind of duplication is allowed in legacy Extended Communities.
If a field in a specific type of XXC is invalid in another setting, it is not by default to be considered invalid in a XXC. For example, 0 is an invalid AS number when used in an AS path attribute. That does not make it invalid as an ASN in the AS-Specific XXC. The behavior and validity of fields in XXCs are to be defined by a specification of the specific type and sub-type of the XXC.
TBD
IANA is requested to assign a BGP path attribute value for the Extra Extended Community attribute.
IANA is requested to create and maintain registries as detailed in the following sections. For each registry, the allocation policies as per [RFC8126] are stated for the ranges of values and some values are allocated by this document.
Range Allocation Policy
--------- ------------------------------
0-31 First Come First Served
32-47 Experimental
48-63 Standards Action
Value Description Reference
--------- ------------------------------ ---------
0 IPv6-Address-Specific This RFC
1 IPv4-Address-Specific This RFC
2 AS-Specific This RFC
6 EVPN This RFC
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 EVPN ES-Import Route Target This RFC
4 EVPN ESI-EVI Route Target This RFC
6 EVPN Overlay Route Target This RFC
| [I-D.ietf-bess-evpn-igmp-mld-proxy] | Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J. and W. Lin, "IGMP and MLD Proxy for EVPN", Internet-Draft draft-ietf-bess-evpn-igmp-mld-proxy-00, March 2017. |
| [I-D.ietf-bess-evpn-overlay] | Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, J. and W. Henderickx, "A Network Virtualization Overlay Solution using EVPN", Internet-Draft draft-ietf-bess-evpn-overlay-12, February 2018. |