Tunnel Endpoints in BGP

Virtual Aggregation (VA) is a mechanism for reducing FIB size for routers within the AS that deploys VA. This is done through "FIB Suppression", where certain routers in the AS may not install routes to certain prefixes in their FIB. The downside of using VA is that packets addressed to suppressed prefixes transiting the AS may take a longer path than otherwise necessary. For instance, imagine a packet traversing AS-path S-A-B-C-D, where ASes S and D are the service providers for their respective customers. Further, assume that ASes A, C, and D are using VA, and that A and C are FIB-suppressing the prefix associated with the packet. In this case, when the packet transits A and C, there is a good chance that it will take an extra router hop within A and C. This increases load for A and C, and degrades performance for S's and D's customers. The mechanism described in this draft allows D, for instance, to associate a tunnel endpoint with the prefixes that it originates. The tunnel endpoint is an anycasted address that terminates at all of D's routers. If A and C FIB-install the route to the prefix associated with the tunnel endpoint, then packets tunneled to the FIB-suppressed prefix will take the shortest path. This draft describes a mechanism for advertising the tunnel endpoint address in BGP. It does so without changes to how BGP computes routes, and in such a way that packets always follow the expected AS path. In other words, a tunnel T to a prefix P is not used unless the AS-path of the tunnel route and the AS-path of the prefix route are the same. This draft uses the Tunnel Encapsulation Attribute (TE-Attribute) defined in to encode the tunnel information. However, whereas couples the TE-Attribute with the "Encapsulation SAFI", this draft uses the TE-Attribute in normal BGP updates transmitted over multiple ASes across the Internet. This draft extends the use of the optional, transitive TE-Attribute defined in section 4 of . Its purpose, as defined in , is to allow a router acting as a tunnel endpoint to signal its tunnel type and tunnel parameters. The TE-Attribute does not convey the actual IPv4 or IPv6 address of the tunnel endpoint. Rather, this information is carried in the NEXT_HOP field of BGP. As such, the scope of is only within the set of routers that do not change the NEXT_HOP field. This draft extends the use of the TE-Attribute so that it can be passed from AS to AS in normal BGP reachability updates.

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 .

This draft defines a new sub-TLV to be used with the TE-Attribute, the "Endpoint Address" sub-TLV. The sub-TLV Type is TBD. The sub-TLV Value field is defined as:

The Autonomous System (AS) Number is that of the AS originating the route. The Endpoint Address is that of the tunnel endpoint.

The following usage rules apply only to TE-Attributes that are NOT associated with an encapsulating SAFI (i.e. as defined by ) and that include an Endpoint Address Sub-TLV.

Only the router originating a route may include a TE-Attribute. In other words, the TE-Attribute MUST NOT be added to received routes. The AS number in the Endpoint Address Sub-TLV MUST match that used as the first AS in the AS path. The Endpoint Address itself does not have to be from the same AF as the reachable NLRI in the update. The reachable NLRI may be both IPv4 and IPv6. However, there MUST be an NLRI in the UPDATE that contains the endpoint address. An originating AS as defined here may be an AS that receives a route from a customer that uses a private AS number. If a tunnel endpoint router receives a packet on the tunnel, and the only known route to the destination is via routes originated by other ASes (not including private ASes of customers), then the packet must be dropped. This prevents transient loops whereby the ASes of a multi-homed customer both think that the other AS can reach the customer. Once the route withdraw reaches all other ASes, no more packets will be received via the tunnel. All routers in the origin AS MUST use the same Endpoint Address, which is anycasted across all routers. The reason for imposing this restriction is as follows. Say that an origin AS used different endpoint addresses for different routers, and that an upstream AS that does not recognize the TE-Attribute decided to aggregate two UPDATEs with different endpoint addresses. The aggregating AS might drop one of the TE-Attributes but include the other, with the result that the tunnel endpoint in the resulting UPDATE would be undetectably incorrect with respect to some of the NLRI in the UPDATE. The complete TE-attribute produced by all routers in the originating AS MUST be identical. The Protocol and Color Sub-TLV types are not used. If the encapsulation technique is GRE, and no key value is used, then the Endpoint Address Sub-TLV is the only one required. If the key value is used, or L2TPv3 is the tunnel type, then the Encapsulation Sub-TLV associated with the tunnel type is included. Note that even though the above paragraph states that the TE-attribute produced by all routers must be identical, in practice this is not strictly possible. If an AS decides to modify the endpoint address it uses, or decides to modify the tunnel type or tunnel parameters it uses, then for some period of time different routers will in fact be producing different TE-Attributes (i.e. while routers are being reconfigured). When this is the case, all routers MUST be able to receive tunneled packets for every TE-Attribute being produced by any router in the AS. For example, assume that an AS wants to modify its TE-Attributes from tunnel A to tunnel B (where A and B have different endpoint address, different tunnel types, or different tunnel parameters). The network administrator would first configure all routers to accept both tunnels A and B. He or she would then modify routers to produce TE-Attributes for tunnel B. After that was complete, he or she would delete tunnel A from all routers. It is for further study whether IP-in-IP encapsulation is required. It is also for further study whether multiple encapsulation types are required for the same UPDATE (i.e. to allow a remote router with limited encapsulation types to be able to select an encapsulation type that works for it.)

ASes that have deployed VA SHOULD FIB-install routes containing the Endpoint Address. This will prevent packets tunneled to Endpoint Addresses from taking any extra hops. When a router in a non-originating AS receives a route with an associated Endpoint Address, it must decide whether or not to use the tunnel. The router always has the option of ignoring the tunnel (and will do so by default if it does not recognize the TE-attribute). This section describes the criteria that determines when the router may use the tunnel. The router MUST NOT use the tunnel UNLESS the following criteria are met: The AS_PATH to the tunnel endpoint matches the AS path to the reachable prefix. The AS_PATH advertised by the AS, for all NLRI for which a tunnel is used, matches that of the tunnel. The first AS in the AS_PATH Attribute is in an AS-SEQUENCE (not an AS-SET), and this AS matches the AS in the TE-attribute. This prevents an error whereby an aggregating AS combines NLRI from different originating ASes, and throws away all but one of the TE-attributes, thus resulting in an Endpoint Address that is incorrect. If there are multiple TE-attributes in the update, they MUST all be identical. In this case, the AS SHOULD delete all but one of the TE-attributes from UPDATEs it passes on. If they are not all identical, then the AS MUST ignore them and remove all of them from any UPDATES that it passes on. Note that the above rules have the characteristic that, if a transit AS decides to use one AS path to some prefixes from an origin AS, and another AS path to other prefixes from the origin AS, then only one of these paths can have a valid endpoint address associated with it. Packets transmitted to the other path cannot be tunneled. One way to fix this, that would require changes to this draft, would be to encode the tunnel endpoint as a block of addresses. In this case, the transit AS that wishes to use multiple paths to different prefixes from an origin AS can deaggregate the block of addresses, and associate one tunnel endpoint block deaggregate with each selected path. Whether this is a good idea is for further study.

IANA must issue a new Sub-TLV type for the Tunnel Encapsulation Attribute for the Endpoint Address Sub-TLV.

Because there are no changes in the BGP route selection process, there are no changes to the security properties of BGP as a result of this draft.