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 **** The title should probably be: "The BGP 'Extra-Long Extended **** Communities' Attribute", as (a) the attribute contains multiple **** communities, and (b) the name "extra extended communities" implies that **** the attribute carries more extended communities than usual, which **** doesn't really seem to be an accurate description. 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. **** "and are thus longer" than what? 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. **** Extended communities already accommodate IPv6 addresses and four-octet **** AS numbers. **** I suppose what this is trying to say is that there are existing uses of **** the Extended Communities attribute that could benefit from the ability **** to have each extended community carry an auto-derived identifier that **** is between 7 and 22 octets long, and that the Extra Extended **** Communities attribute provides this ability. **** Of course, the obvious question is what are we going to do next year **** when we discover that we need to carry some auto-derived value that is **** 23 octets long? **** The next obvious question is how will this be introduced into EVPN, **** given the fact that every EVPN-PE and every Route Reflector and every **** intermediate ASBR has to support it before it is useful. Not to **** mention the need for the corresponding set of enhancements to Route **** Target Constraint. There would seem to be some backwards compatibility **** issues to address. 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. **** I don't think the new transitivity flags are adequate for their **** purpose, and thus I don't think they will really result in any **** simplification. Further discussio below. 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 September 6, 2018 [Page 1] Internet-Draft BGP Extra Extended Community March 2018 This Internet-Draft will expire on September 6, 2018. Copyright Notice 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. 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 . . . . . 5 7. IPv4-Address-Specific Extra Extended Community type . . . . . 6 8. AS-Specific Extra Extended Community type . . . . . . . . . . 7 9. EVPN Extra Extended Community type . . . . . . . . . . . . . 8 10. EVPN ES-Import Route Target Extra Extended Community sub-type 9 11. EVPN ESI-EVI Route Target Extra Extended Community sub-type . 10 12. EVPN Overlay Route Target Extra Extended Community sub-type . 10 13. Auto-derivation of EVPN RT-XXC . . . . . . . . . . . . . . . 12 14. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 16.1. Registry: BGP Extra Extended Community Types . . . . . . 13 16.2. Registry: IPv6-Address-Specific Extra Extended Community Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 14 16.3. Registry: IPv4-Address-Specific Extra Extended Community Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 14 16.4. Registry: AS-Specific Extra Extended Community Sub-Types 14 16.5. Registry: EVPN Extra Extended Community Sub-Types . . . 14 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.1. Normative References . . . . . . . . . . . . . . . . . . 15 17.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Heitz, et al. Expires September 6, 2018 [Page 2] Internet-Draft BGP Extra Extended Community March 2018 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. **** The main source of complexity in the registries is that the EC type **** field implies the format of the EC value field. (Well, as long as the **** type is not "EVPN" or "Opaque".) It would have been better to define, **** e.g., "Route Target" as a type, and to use a sub-type field to indicate **** which format (e.g., 2-octet-AS-specific, IPv4-address specific) is **** being used. **** In any event, if there's going to be a new attribute of this sort, **** perhaps the type field should be two-octets long. **** With regard to separating the "transitivity" flags from the type field: **** - I see the advantages of this for those extended communities that are **** sometimes used transitively and sometimes used non-transitively. **** However, many extended communities are used only one way or the **** other. With regular extended communities, if extended community X **** can only be used transitively, one allocates a codepoint for **** X-transitive, but does not allocate a codepoint for X-non-transitive. **** With the proposed extra-long extended communities, there is nothing **** to stop someone from sending extended community X with the flags set **** to "non-transitive". This creates more error cases to check for on **** reception. (Or should I say "more error cases to forget to check **** for".) **** - Granted, if there are a whole set of flags governing transitivity, it **** does become impractical to try to work those flags into the **** codepoint. **** However, assuming that one wants to separate the transitivity flags **** from the codepoint, I don't really see the merit of using a **** non-extensible two-bit flags field or, and I certainly don't see the **** merit of having a 6-bit codepoint field. 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. **** This seems to assume that the notion of "common administration" is **** independent of the particular extended community (i.e., independent of **** the service that uses that community as part of its control plane). **** Suppose service X uses extended community C-X, and service Y uses **** extended community C-Y. Let's consider a pair of contiguous ASes, AS1 **** and AS2. Service X is a service that is offered in both ASes, under a **** common administration. Service Y is also offered in both ASes, but **** under different administrations. How does one use a two-bit **** transitivity field to tell the ASBRs "propagate C-X but not C-Y". **** This scenario could easily exist if two networks are being merged, but **** only some of the services are being transitioned to a common **** administration. Or if L3VPN is managed by a single admin across both **** ASes, but EVPN is managed by a different admin in each AS. **** I don't think that the "attribute scoping" problem can in general be **** solved with a two-bit field. 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 offered in this document will simplify policies that are used to distribute communities. **** It might be more accurate to say that for a particular set of use **** cases, the policy may be simpler. If the "administrative domains" are **** not identical for all extended communities, one still needs policies. 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). Each XXC is encoded as a 24-octet quantity, as follows: **** Why 24, rather than 26 or 28 or 37 or any other number? 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 September 6, 2018 [Page 3] Internet-Draft BGP Extra Extended Community March 2018 Type - 6 bits. IANA will maintain a registry of types. Four types are described in this document. **** For a second I thought "6 bits" was a typo for "16 bits" ;-) Sub-type - 8 bits. IANA will maintain a registry of sub-types for each registered type. All even numbered Sub- Types are a route target. **** "All even numbered sub-types are a route target." I'm not sure I **** understand what is being said here. It certainly doesn't appear to be **** in-line with the goal of simplifying the registries. If the intention **** is that certain values in the range are only assignable to certain **** types of extended community, I think that makes it very difficult for **** IANA to administer the registration policy. Value - The actual information according to the type and sub-type. **** It might be better just to say "the syntax and semantics of the value **** field depend upon the type and sub-type". 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]. **** Why wouldn't that depend on the administrative scope of the service **** that is using the extended community? The values are: 0 - The XXC is transitive across ASes. 1 - The XXC is not transitive across ASes. 2 - The XXC is transitive across ASes under the same administration only. 3 - 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. **** Value 3 assumes that the control path between two ASes of the same **** administration will not include an AS of a different administration. I **** wonder if that's a valid assumption. To be not transitive means that a receiving BGP speaker MUST silently discard the community by default **** Please say exactly what is meant by "discard the community". **** Does "silently" in this context mean "don't generate a log entry"? **** Probably it just means that when an UPDATE with a given NLRI and a **** given XXC is received on a BGP session for which that XXC is **** non-transitive, the default behavior MUST be to remove that XXC from **** the XXC attribute before propagating an UPDATE containing that NLRI. **** Of course, this could result in an XXC attribute that has no XXCs. Is **** the intention to propagate the empty attribute, or to elide it? (Later **** on there is some text that suggests an UPDATE with an empty XXC **** attribute is malformed, so I guess sending such an XXC attribute has to **** be prohibited, and one would have to remove the XXC attribute if it **** becomes empty. and a sending speaker MUST not send the community by default. **** Perhaps rephrase to "the default behavior MUST be that an XXC is not **** sent on a BGP session for which that XXC is non-transitive". (The **** definition of "transitive" might need to be wordsmithed a bit so that **** it is clear what it means for an extended community to be transitive on **** a particular BGP session.) A speaker MAY send or receive a non- transitive XXC if explicitly configured to do so. **** Well there goes the simplicity. 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. **** It won't be long before this devolves into a boolean per XXC **** type/sub-type, which will take us right back to the problem of "complex **** and error prone" configurations. 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. **** One can imagine the spec for a particular type/sub-type saying that T=3 **** is not a valid value for that type/sub-type. If the originator puts in **** 3 by error, this error will not be detectable on the other side of the **** border. (I don't think we want to require the ASBRs to understand the **** service and to be able to detect such errors.) **** I thought of suggesting that there be a value 4, which means "I used to **** be 3 but I've passed through an admin domain boundary already". But **** there's no room for a 4 in the transitivity field ;-) As an exception, a route server as defined in [RFC7947] SHOULD NOT change the transitivity field. **** Well, it didn't take long to find the first exception. No doubt the **** first of many. Perhaps it would be good to state the principles **** governing the decision to violate the general rules for handling the T **** field, instead of just pointing to a single case. Also, some systems **** may function as RRs for certain route types, but as border routers for **** certain other route types. So a session could need to be configured **** with the list of extended communities for which it should or 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 Heitz, et al. Expires September 6, 2018 [Page 4] Internet-Draft BGP Extra Extended Community March 2018 Transitivity field should be set by the originator based upon individual circumstances at the originator. The transitivity is not assigned by IANA. **** There may be cases where certain XXC type/sub-types are only defined **** or valid for certain values of T. The draft should say something about **** the handling of cases where the combination is invalid. 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 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. **** Perhaps: "if the Capability has not been received over a given session, **** the default behavior MUST be that a BGP speaker does not send, on that **** session, any XCC whose transitivity is non-zero on that session." **** Then start compiling all the exceptions, e.g., route reflectors, route **** servers, etc. There may also be exception lists for each extended **** community. 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. **** So you have to know whether your peer on a given session is a route **** reflector that does not forward traffic and whose clients all support **** XXC. What happened the goal of eliminating "complex and error-prone" **** configuations? (And what would happen if the RR suddenly opens a **** session with a client that does not support XXC?) 5. Constrained Route Distribution [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. **** Please explain how the value of the transitivity flags impacts the **** possibility of aggregation. 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. 6. IPv6-Address-Specific Extra Extended Community type Heitz, et al. Expires September 6, 2018 [Page 5] Internet-Draft BGP Extra Extended Community March 2018 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. **** "assigned by IANA for individual functions"? 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. **** The address must be assigned to the administration of the service that **** is 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. **** I wonder if the "Local Administrator" field is long enough. It is 12 **** octets shorter than in the other XXC types. This could have a negative **** impact if one wants to fill in this field with auto-derived values that **** are independent of the type of the GA field. 7. IPv4-Address-Specific Extra Extended Community type Heitz, et al. Expires September 6, 2018 [Page 6] Internet-Draft BGP Extra Extended Community March 2018 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. **** assigned to the administation 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 September 6, 2018 [Page 7] Internet-Draft BGP Extra Extended Community March 2018 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. **** assigned to the administation of the service using the XXC. 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. EVPN Extra Extended Community type This is a Extra Extended Community type with a Value field comprising 22 octets. Heitz, et al. Expires September 6, 2018 [Page 8] Internet-Draft BGP Extra Extended Community March 2018 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. 10. EVPN ES-Import Route Target Extra Extended Community sub-type **** The use of the XXCs by EVPN might be better discussed in an EVPN draft. 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. **** Doesn't this raise a backwards compatibility issue? 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 Type field is 6. The Sub-Type is 2. The fields are as follows: GA - 4 octets. Global Administrator. This is the Autonomous System Number of the AS where this RT is assigned. **** This field does not appear to be present in the ES-Import Route Target **** as defined in RFC 7432. Why is it needed here? Heitz, et al. Expires September 6, 2018 [Page 9] Internet-Draft BGP Extra Extended Community March 2018 Zero - 8 octets filled with 0. Must be ignored by the receiver. ESI - 10 octets. Ethernet Segment Identifier. 11. 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]. **** The term "ESI-EVI Route Target" does not appear to occur in the cited **** draft. Perhaps the "ES-Import" Route Target from RFC 7432 is what is **** meant? **** I would be strongly opposed to having **** draft-ietf-bess-evpn-igmp-mld-proxy make a normative reference to this **** draft. Of course, that's a discussion for BESS not IDR. 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 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. **** Why is this field needed? Zero - 4 octets filled with 0. Must be ignored by the receiver. ESI - 10 octets. Ethernet Segment Identifier. EVI - 4 octets. Ethernet Tag ID. **** In EVPN, I believe that "EVI" and "Ethernet Tag ID" are two completely **** different things. 12. 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. More details are in [I-D.ietf-bess-evpn-overlay]. **** The details seem very well-hidden. Could a more specific citation be **** provided? Heitz, et al. Expires September 6, 2018 [Page 10] Internet-Draft BGP Extra Extended Community March 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. **** Please explain why this use of the GA field makes sense. A - A single bit indicating if this RT is auto-derived 0 : auto-derived 1 : manually derived **** Why is this bit needed? 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) **** References to where the use of these spaces is explained? Domain - 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 **** This is the sort of thing the "Global Administrator" (GA) field was **** originally defined for. I'm not sure I understand how a one-octet **** field with an undefined scope and an unspecified allocation procedure **** is going to be used to ensure the necessary amount of uniqueness. Heitz, et al. Expires September 6, 2018 [Page 11] Internet-Draft BGP Extra Extended Community March 2018 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. **** Is the length of the Service-ID supposed to be implied by the codepoint **** in the "Space" field? If so, please cite the references. 13. Auto-derivation of EVPN RT-XXC 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. **** That's why the ECs were defined with a "Global Administrator" (GA) **** field. The GA field is supposed to be a globally unique identifier of **** the authority that is assigning values to be carried in the "Local **** Administrator" (LA) field. **** I don't really understand how that role is to be filled by a **** "discriminator" bit field of undefined length, whose values do not seem **** to be subject to any particular allocation policy. **** One can't just keep throwing in fields and then tell the operators **** "figure out how to set all these fields so that their concatenated **** value is unique". 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. 14. 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 non-zero multiple of 24. **** Then it should be mentioned up front that an XXC attribute MUST contain **** one or more communities. The error SHALL be handled using the approach of "treat-as- withdraw" as described in Section 2 of [RFC7606]. **** Is "treat-as-withdraw" a bit of an overreaction to the presence of an **** XXC attribute with zero communities? 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. **** Please define "duplicate". Does this mean all 24 octets are duplicated **** exactly? If not, what does it mean? 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. **** Please define "silently discard". 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 Heitz, et al. Expires September 6, 2018 [Page 12] Internet-Draft BGP Extra Extended Community March 2018 a different XXC increments it by 10, then the combination will cause an increment of 15. **** I'm glad to see an example, because it shows clearly that the "discard **** duplicates" rule is very problematic. If we have an XXC of type A that **** means "increment something by x seconds", and another of type B that **** means "increment something by y milliseconds", then why would **** <,> have a different effect than **** <,>? Does that make sense? **** Of course, using an extended community to cause an increment or **** decrement operation is perhaps not such a good idea to begin with. **** Perhaps the semantics of "duplicate communities" should be specific to **** the community (or to a particular service that uses the community)? A BGP speaker MAY send XXCs that are duplicates 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, **** I suspect the transitivity flags will have to be generalized to a more **** finely grained scoping mechanism, in which case it might well make **** sense to have XXCs that have the same but **** different scoping. Suppose one wants to allow one value of the **** community to be processed by systems within some scope, but another **** value to be processed by systems outside that scope? If, by **** coincidence, the two values happened to be the same in some particular **** scenario, it would sense to have duplicates XXCs. **** (Actually, even with the T values defined above, one might want to have **** one value of a given community processed by systems within the admin **** domain, and another by systems in ASes that neighbor the admin domain.) 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. **** Not really, because the ECs would have different type/sub-types, and **** hence would not be duplicates. 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, **** Perhaps "not by default" --> "not necessarily". This is not really a **** matter of defaults, it's a matter of specification (as indicated in the **** following sentences). 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. 15. Security Considerations TBD 16. IANA Considerations 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. 16.1. Registry: BGP Extra Extended Community Types Range Allocation Policy --------- ------------------------------ 0-31 First Come First Served 32-47 Experimental 48-63 Standards Action **** Six-bit type field, no way. Value Description Reference --------- ------------------------------ --------- 0 IPv6-Address-Specific This RFC 1 IPv4-Address-Specific This RFC 2 AS-Specific This RFC 6 EVPN This RFC **** Consider having RT as a type, with the 0,1,2 values above as sub-types. **** One might then consider whether we need an EVPN type, or whether each **** EVPN sub-type can really be considered to be a type of its own. (Same **** with the Opaque ECs.) Heitz, et al. Expires September 6, 2018 [Page 13] Internet-Draft BGP Extra Extended Community March 2018 16.2. Registry: IPv6-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 16.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 16.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 16.5. Registry: EVPN Extra Extended Community Sub-Types 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 Heitz, et al. Expires September 6, 2018 [Page 14] Internet-Draft BGP Extra Extended Community March 2018 17. References 17.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, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [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, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [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, . [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, . [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, . [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, . Heitz, et al. Expires September 6, 2018 [Page 15] Internet-Draft BGP Extra Extended Community March 2018 17.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. [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", draft-ietf-bess-evpn-overlay-12 (work in progress), February 2018. Authors' Addresses Jakob Heitz Cisco 170 West Tasman Drive San Jose, CA, CA 95054 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 September 6, 2018 [Page 16]