Internet DRAFT - draft-heitz-idr-extra-extended-community
draft-heitz-idr-extra-extended-community
IDR J. Heitz
Internet-Draft A. Sajassi
Updates: 4684 (if approved) Cisco
Intended status: Standards Track I. Bagdonas
Expires: July 18, 2019 Equinix
January 14, 2019
BGP Extra Extended Community
draft-heitz-idr-extra-extended-community-02
Abstract
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.
Requirements Language
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].
Status of This Memo
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."
Heitz, et al. Expires July 18, 2019 [Page 1]
Internet-Draft BGP Extra Extended Community January 2019
This Internet-Draft will expire on July 18, 2019.
Copyright Notice
Copyright (c) 2019 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BGP Extra Extended Community Attribute . . . . . . . . . . . 3
3. Transitivity . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Capability . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Constrained Route Distribution . . . . . . . . . . . . . . . 5
6. IPv6-Address-Specific Extra Extended Community type . . . . . 7
7. IPv4-Address-Specific Extra Extended Community type . . . . . 7
8. AS-Specific Extra Extended Community type . . . . . . . . . . 8
9. Route Target Extra Extended Community Sub-Type . . . . . . . 9
10. EVPN Extra Extended Community type . . . . . . . . . . . . . 10
11. EVPN Route Target Extra Extended Community sub-types . . . . 10
12. EVPN ES-Import Route Target Extra Extended Community sub-type 11
13. EVPN ESI-EVI Route Target Extra Extended Community sub-type . 11
14. EVPN Overlay Route Target Extra Extended Community sub-type . 12
15. Duplicate XXC . . . . . . . . . . . . . . . . . . . . . . . . 14
16. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14
17. Security Considerations . . . . . . . . . . . . . . . . . . . 15
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
18.1. Registry: BGP Extra Extended Community Types . . . . . . 15
18.2. Registry: IPv6-Address-Specific Extra Extended Community
Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 15
18.3. Registry: IPv4-Address-Specific Extra Extended Community
Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 16
18.4. Registry: AS-Specific Extra Extended Community Sub-Types 16
18.5. Registry: EVPN Extra Extended Community Sub-Types . . . 16
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
19.1. Normative References . . . . . . . . . . . . . . . . . . 17
19.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Heitz, et al. Expires July 18, 2019 [Page 2]
Internet-Draft BGP Extra Extended Community January 2019
1. Introduction
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.
2. BGP Extra Extended Community Attribute
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).
The attribute SHOULD contain at least one XXC.
Each XXC is encoded as a 24-octet quantity, 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 | Type | Sub-Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as shown below:
T - Transitivity field (2 bits). This is further
described below.
Heitz, et al. Expires July 18, 2019 [Page 3]
Internet-Draft BGP Extra Extended Community January 2019
Type - 6 bits. IANA will maintain a registry of types.
Four types are described in this document.
Sub-type - 8 bits. IANA will maintain a registry of sub-types
for each registered type.
Value - The actual information according to the type and
sub-type.
Two XXCs are considered equal when all the 24 octets of the XXCs are
equal, except the Transitivity field..
3. Transitivity
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:
0 - Transitive: The XXC is transitive across ASes.
1 - Non-transitive: The XXC is not transitive across ASes.
2 - Administration Transitive: The XXC is transitive across
ASes under the same administration only.
3 - One-time Transitive: The XXC is transitive across ASes
under the same administration and into an AS under the
neighboring administration, but not into an AS under a
further administration.
To be not transitive means that a sending speaker MUST not send the
community. A speaker that receives an XXC across an AS boundary not
allowed by the transitivity of that XXC MUST treat the containing
UPDATE message as malformed.
A single administration may own a multitude of contiguous ASes. XXCs
with transitivity types 2 and 3 are transitive between these ASes.
By default, an EBGP neighbor is assumed to be under a different
administration. If an EBGP neighbor session is to a speaker in the
same administration, then it needs to be configured as such. No
Administration identifiers are required. The configuration just
needs to specify "Same Administration". There is no new field in the
BGP OPEN message to indicate administration membership.
A BGP speaker that receives a XXC with transitivity 3 from a neighbor
in an AS under a different administration SHOULD change the
transitivity field of the XXC to 2.
Heitz, et al. Expires July 18, 2019 [Page 4]
Internet-Draft BGP Extra Extended Community January 2019
The transitivity of an XXC is intended to limit the travel of the XXC
in default conditions. It prevents an XXC from traveling far beyond
its intended reach if nothing else is done. That means a speaker is
free to change the transitivity of an XXC according to local policy
to support specific use cases. As an example, a route server as
defined in [RFC7947] MAY choose not to change transitivity from 3 to
2. The definition of an XXC type MAY include a specification of the
default transitivity for the type.
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.
4. Capability
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 SHOULD NOT send a XXC, the transitivity of which is not 0, to
a speaker from which it has not received the Extra Extended Community
Capability in its OPEN message. A BGP speaker SHOULD withdraw a
route from a neighbor if that neighbor does not advertise this
capability and the route contanis an XXC. These rules are intended
to prevent XXCs from leaking outside their intended range. There may
be cases where such leaking causes no ill effects and the rules can
be safely ignored. Such cases are beyond the scope of this document.
A transitive XXC may be sent to a neighbor that has not sent the
capability.
5. Constrained Route Distribution
[RFC4684] defines Constrained Route Distribution. That document is
updated as follows:
The Extra Constrained Route Distribution SAFI is defined, the NLRI of
which is as follows:
Heitz, et al. Expires July 18, 2019 [Page 5]
Internet-Draft BGP Extra Extended Community January 2019
+-------------------------------+
| AFI (2 octets) |
+-------------------------------+
| SAFI (1 octets) |
+-------------------------------+
| origin AS (4 octets) |
+-------------------------------+
| XXC value (24 octets) |
+ +
| |
+-------------------------------+
The fields are as shown below:
AFI - The filter specified in this NLRI applies only to
prefixes with this AFI.
SAFI - The filter specified in this NLRI applies only to
prefixes with this SAFI.
origin AS - Routes that do not have this origin AS will be
blocked by the filter.
XXC value - Routes that do not have this XXC will be blocked by
the filter.
This works the same way as [RFC4684] with the following differences:
- The maximum prefix size of this NLRI is 248 bits.
- The minimum prefix size of this NLRI is 56 bits except for the
default route, which is 0 bits long.
- The filter applies only to prefixes that have the specified AFI/
SAFI.
- The filter applies to any XXC values. The filtered XXC does not
need to be designated a "Route Target".
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 AFI, SAFI, Transitivity, Route
Target Type, Sub-Type and the Global Administrator Route Target
fields MUST NOT be aggregated.
The address family "Extra Constrained Route Distribution" cannot
filter itself.
Heitz, et al. Expires July 18, 2019 [Page 6]
Internet-Draft BGP Extra Extended Community January 2019
6. IPv6-Address-Specific Extra Extended Community type
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 as
detailed in the IANA Considerations section.
The Value field consists of 2 sub-fields:
Global Administrator sub-field: 16 octets
This sub-field contains an IPv6 unicast address assigned by one
of the Internet registries to the administration of the service
using the XXC.
Local Administrator sub-field: 6 octets
The organization identified by the IP address in the Global
Administrator sub-field can encode any information in this sub-
field. The format and meaning of the value encoded in this
sub-field should be defined by the sub-type of the XXC.
7. IPv4-Address-Specific Extra Extended Community type
Heitz, et al. Expires July 18, 2019 [Page 7]
Internet-Draft BGP Extra Extended Community January 2019
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:
Global Administrator sub-field: 4 octets
This sub-field contains an IPv4 unicast address assigned by one
of the Internet registries to the administration of the service
using the XXC.
Local Administrator sub-field: 18 octets
The organization identified by the IP address in the Global
Administrator sub-field can encode any information in this sub-
field. The format and meaning of the value encoded in this
sub-field should be defined by the sub-type of the XXC.
8. AS-Specific Extra Extended Community type
Heitz, et al. Expires July 18, 2019 [Page 8]
Internet-Draft BGP Extra Extended Community January 2019
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:
Global Administrator sub-field: 4 octets
This sub-field contains a 4-octet Autonomous System number
assigned by IANA. Note that an ASN that is less than 65536 in
value is represented in 4 octets by setting the higher two
octets to 0.
Local Administrator sub-field: 18 octets
The organization identified by the Autonomous System number in
the Global Administrator sub-field can encode any information
in this sub-field. The format and meaning of the value encoded
in this sub-field should be defined by the sub-type of the XXC.
9. Route Target Extra Extended Community Sub-Type
For each of the Types of XXC: IPv4-Address-Specific, IPv6-Address-
Specific and AS-Specific, the Sub-Type 2 denotes a Route-Target. It
has the same use as the Route Target defined in [RFC4360] Sec. 4.
The XXC route targets are independent of the RFC4360 Route Targets.
There is no way to convert between the two. Either or both may be
used in any deployment.
Heitz, et al. Expires July 18, 2019 [Page 9]
Internet-Draft BGP Extra Extended Community January 2019
10. EVPN Extra Extended Community type
This is a Extra Extended Community type with a Value field comprising
22 octets.
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 +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 6. The Sub-Type is to be assigned by IANA for
individual functions. Three functions are defined in this document.
11. EVPN Route Target Extra Extended Community sub-types
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.
EVPN XXC route targets have a Type value of 6. The value of the Sub-
Type is
1 - AS-Specific: The most significant 4 octets of the Value
field are the Autonomous System Number of the AS where this
RT is assigned.
2 - IPv4 Address Specific: The most significant 4 octets of the
Value field are an IPv4 unicast address assigned by one of
the Internet registries to the administration of the
service using the XXC.
3 - IPv6 Address Specific: The most significant 16 octets of
the Value field are an IPv6 unicast address assigned by one
of the Internet registries to the administration of the
service using the XXC.
Heitz, et al. Expires July 18, 2019 [Page 10]
Internet-Draft BGP Extra Extended Community January 2019
The Ethernet Tag ID is placed into the least significant octets of
the Value field. The remaining octets are 0.
12. EVPN ES-Import Route Target Extra Extended Community sub-type
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 ES-Import Route Target XXC and the ES-Import
Route Target extended community are independent. Either or both may
be used in any deployment. There is no conversion from one to the
other.
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.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ ESI +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Zero +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 6. The Sub-Type is 4. The fields are as follows:
GA - 4 octets. Global Administrator. This is the
Autonomous System Number of the AS where this RT is
assigned.
ESI - 10 octets. Ethernet Segment Identifier.
Zero - 8 octets filled with 0. Must be ignored by the
receiver.
13. EVPN ESI-EVI Route Target Extra Extended Community sub-type
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].
Heitz, et al. Expires July 18, 2019 [Page 11]
Internet-Draft BGP Extra Extended Community January 2019
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 | 5 | GA :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: GA (Cont.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ ESI +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVI-RT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 6. The Sub-Type is 5. The fields are as follows:
GA - 4 octets. Global Administrator. This is the
Autonomous System Number of the AS where this RT is
assigned.
ESI - 10 octets. Ethernet Segment Identifier.
EVI-RT - 4 octets. The least significant 4 octets of the
Local Administrator field of the route target
associated with the EVI.
Zero - 4 octets filled with 0. Must be ignored by the
receiver.
14. EVPN Overlay Route Target Extra Extended Community sub-type
This EVPN Overlay Route Target Extra Extended Community type is used
to filter routes based upon the identifier used in the specified
overlay protocol. It works the same way as the RT described in
[RFC8365] Sec. 5.1.2.1. It simply provides more room in the fields
to allow auto-derivation for more cases. First, it allows a 4 octet
AS number. Second, the Service ID is large enough to fit any of the
selected IDs.
Heitz, et al. Expires July 18, 2019 [Page 12]
Internet-Draft BGP Extra Extended Community January 2019
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 | D-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ +
| Service-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is 6. The Sub-Type is 6. The fields are as follows:
GA - 4 octets. Global Administrator. This is the
Autonomous System Number of the AS where this RT is
assigned.
A - A single bit indicating if this RT is auto-derived
0 : auto-derived
1 : manually derived
Space - 7 bits. The identifier space appropriate to the
service. The following spaces are defined:
0 : VID (802.1Q VLAN ID)
1 : VXLAN
2 : NVGRE
3 : I-SID
4 : EVI
5 : dual-VID (QinQ VLAN ID)
D-ID - 1 octet. The default value of domain-id is zero
indicating that only a single numbering space exists
for a given technology. However, if there is more
than one number space for a given technology (e.g.,
overlapping VXLAN spaces), then each of the number
Heitz, et al. Expires July 18, 2019 [Page 13]
Internet-Draft BGP Extra Extended Community January 2019
spaces need to be identified by their corresponding
domain-id starting from 1.
Service-ID - 16 octets. VNI, VSID, I-SID, VID or other identifier
as appropriate for the service specified in the Space
field. If the contained identifier is less than 16
octets long, then it is placed in the least
significant octets of the Service-ID field with the
higher octets being filled with 0.
15. Duplicate XXC
Two XXCs are considered duplicate if the values of each field except
the Transitivity field match.
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 that receives duplicate XXCs that differ in the
Transitivity MAY silently discard the XXC with the more restrictive
transitivity.
16. Error Handling
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 multiple of 24. The
error SHALL be handled using the approach of "treat-as-withdraw" as
described in Section 2 of [RFC7606]. Receipt of a zero length Extra
Extended Communities attribute SHALL be treated as "attribute-
discard".
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.
If a field in a specific type of XXC is invalid in another setting,
it is not necessarily 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
Heitz, et al. Expires July 18, 2019 [Page 14]
Internet-Draft BGP Extra Extended Community January 2019
behavior and validity of fields in XXCs are to be defined by a
specification of the specific type and sub-type of the XXC.
The receipt of an XXC that violates the transitivity rules SHALL be
handled using the approach of "treat-as-withdraw".
17. Security Considerations
TBD
18. IANA Considerations
IANA is requested to assign a SAFI for the Extra Constrained Route
Distribution address family.
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.
18.1. Registry: BGP Extra Extended Community Types
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
18.2. Registry: IPv6-Address-Specific Extra Extended Community Sub-
Types
Heitz, et al. Expires July 18, 2019 [Page 15]
Internet-Draft BGP Extra Extended Community January 2019
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
18.3. Registry: IPv4-Address-Specific Extra Extended Community Sub-
Types
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
18.4. Registry: AS-Specific Extra Extended Community Sub-Types
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
2 Route Target RFC4360
18.5. Registry: EVPN Extra Extended Community Sub-Types
Range Allocation Policy
--------- ------------------------------
0-191 First Come First Served
192-255 IETF Review
Value Description Reference
--------- ------------------------------ ---------
1 EVPN AS-Specific Route Target This RFC
2 EVPN IPv4-Specific Route Target This RFC
3 EVPN IPv6-Specific Route Target This RFC
4 EVPN ES-Import Route Target This RFC
5 EVPN ESI-EVI Route Target This RFC
6 EVPN Overlay Route Target This RFC
Heitz, et al. Expires July 18, 2019 [Page 16]
Internet-Draft BGP Extra Extended Community January 2019
19. References
19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016,
<https://www.rfc-editor.org/info/rfc7947>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Heitz, et al. Expires July 18, 2019 [Page 17]
Internet-Draft BGP Extra Extended Community January 2019
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
19.2. Informative References
[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", draft-ietf-
bess-evpn-igmp-mld-proxy-00 (work in progress), March
2017.
Authors' Addresses
Jakob Heitz
Cisco
170 West Tasman Drive
San Jose, CA, CA 95134
USA
Email: jheitz@cisco.com
Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA, CA 95134
USA
Email: sajassi@cisco.com
Ignas Bagdonas
Equinix
London
UK
Email: ibagdona.ietf@gmail.com
Heitz, et al. Expires July 18, 2019 [Page 18]
