Simple Tunnel Endpoint Signaling in BGP
draft-xu-tunnel-00.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 15, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

Virtual Aggregation (VA) is a mechanism for shrinking the size of the DFZ FIB in routers [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.). VA can result in longer paths and increased load on routers within the ISP that deploys VA. This document describes a mechanism that allows an AS that originates a route to associate a tunnel endpoint terminating at itself with the route. This allows routers in a remote AS to tunnel packets to the originating AS. If transit ASes between the remote AS and the originating AS install the prefixes associated with tunnel endpoints in their FIBs, then tunneled packets that transit through them will take the shortest path. This results in reduced load for the transit AS, and better performance for the customers at the source and destination.

Table of Contents

1.  Introduction
    1.1.  Requirements notation
2.  Document revisions
3.  Syntax of the Tunnel Address Attribute
4.  Usage of the Tunnel Address and TE-Encap Attributes
    4.1.  Originating AS
    4.2.  Non-Originating ASes
5.  IANA Considerations
6.  Security Considerations
7.  Normative References
§  Authors' Addresses

1.  Introduction

Virtual Aggregation (VA) [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.) 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 address with the prefixes that it originates. The tunnel endpoint address can be an anycasted address that terminates at some or all of D's routers. If A and C FIB-install the route to the prefix associated with the tunnel endpoint address, then packets tunneled to the FIB-suppressed prefix will take the shortest path.

This draft describes a mechanism for advertising the tunnel endpoint address across ASes in BGP.

This draft uses both the Address Specific BGP Extended Communities Attribute for IPv4 and IPv6 to carry the tunnel endpoint address ([RFC4360] (Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” February 2006.) and [I‑D.ietf‑l3vpn‑v6‑ext‑communities] (Rekhter, Y., “IPv6 Address Specific BGP Extended Communities Attribute,” December 2008.) respectively). Where additional tunnel parameters must be signaled (i.e. for GRE or L2TP), this draft uses the Tunnel Encapsulation Attribute (TEncap-Attribute) defined in [I‑D.ietf‑softwire‑encaps‑safi] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.) to encode these parameters.

1.1.  Requirements notation

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Document revisions

This draft was previously released with file name draft-xu-idr-tunnel-00.txt. The changes from that draft are as follows:

1. The need for a new sub-TLV definition in [I‑D.ietf‑softwire‑encaps‑safi] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.) has been eliminated (in favor of the Address Specific BGP Extended Communities Attribute).
2. The need to carry the AS number of the originating AS separate from the AS-Path attribute has been eliminated.
3. The requirement that the AS-path to the tunnel endpoint address and the AS-path to the destination prefix be the same was dropped. As a result, however, legacy ASes may believe that packets take a different AS-path than the one they actually take.
4. The mechanism to avoid transient loops between providers of multi-homed sites has been made optional rather than required.

3.  Syntax of the Tunnel Address Attribute

This draft defines a new type for the Address Specific BGP Extended Communities Attribute for both IPv4 and IPv6 to be used as the Tunnel Address Attribute. The value of the high-order octet for the IPv4 type field is 0x01 as defined in [RFC4360] (Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” February 2006.) and for the IPv6 type field it is 0x00 as defined in [I‑D.ietf‑l3vpn‑v6‑ext‑communities] (Rekhter, Y., “IPv6 Address Specific BGP Extended Communities Attribute,” December 2008.). The attribute is transitive across ASes. The value of the low-order octet for the type field (i.e. the Sub-Type) is (TBD by IANA) for IPv4 and (TBD by IANA) for IPv6.

The Global Administrator field is set to the Tunnel Address. This is the IP address of the tunnel endpoint.

The Local Administrator field is set to zero and ignored upon receipt.

If the Tunnel Attribute (TEncap-Attribute) defined in [I‑D.ietf‑softwire‑encaps‑safi] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.) is not present, then the encapsulation type is assumed to be IP-in-IP. If the encapsulation type is GRE or L2TP, then the TEncap-Attribute must be present. It defines the parameters associated with the tunnel as specified in [I‑D.ietf‑softwire‑encaps‑safi] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.).

4.  Usage of the Tunnel Address and TE-Encap Attributes

4.1.  Originating AS

The "Originating AS" is defined here as the AS whose AS number is the first AS in the AS path. Only the AS originating a route may include a Tunnel Address Attribute and optional TEncap-Attribute. The TEncap-Attribute is included only if the tunnel type is something other than IP-in-IP (i.e. GRE or L2TP). In the remainder of this draft, the Tunnel Address Attribute alone, or both together, are referred to as the "Tunnel Attributes". The Tunnel Attributes MUST NOT be added to externally received routes (i.e. via eBGP), except in the case where the sole AS number of the received route is a private AS number, and it is replaced by that of the receiving AS. The reachable NLRI in the update may be both IPv4 and IPv6.

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 may be dropped. This prevents transient loops whereby a multi-homed customer is unreachable by both of its provider ASes, but neither AS has yet heard the withdraw from the other AS, and so both think that the other AS can reach the customer. On the other hand, in the case where the customer is reachable via the other AS, a policy of dropping such packets causes unnecessary packet loss.

The originating AS may of course aggregate the prefixes of customers reachable via multiple routers. In this case there must be only one tunnel endpoint address for the aggregated prefix. This in turn suggests that the tunnel endpoint address is common to all of the routers. In other words, the tunnel endpoint address must be anycasted across the routers. More generally, the tunnel endpoint address should be anycasted across all routers in the origin AS.

Note that if different routers that originate a route for the same aggregated prefix use different tunnel endpoint addresses, the following problem can occur. Imagine that there are two routers R1 and R2 that are originating routes to the same prefix but use different tunnel endpoint addresses. Now, assume that router R1 crashes. There is no way to withdraw the tunnel endpoint: R2 has no mechanism with which do it. As a result, remote routers with packets destined for sites attached to R2 may nevertheless tunnel them to R1 causing them to be dropped.

It is possible that different routers with the same tunnel endpoint address advertise different tunnel parameters or even tunnel types in their respective TEncap-Attributes. This is allowed, however all such routers must be able to accept tunnels for every advertised tunnel.

4.2.  Non-Originating ASes

ASes that have deployed VA should FIB-install any routes containing a tunnel endpoint address. This will prevent packets tunneled to tunnel endpoint addresses from taking any extra hops.

When a router in a non-originating AS receives a route with an associated tunnel 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 tunnel attributes).

A router may choose to tunnels where the AS_PATH to the tunnel endpoint address does not match the AS path to the reachable prefix. There are pros and cons to doing this. On the plus side, doing this means that the AS-path taken by the packet is the same as the AS-path in the route to the destination prefix. This in turn means that the AS-path that upstream legacy ASes see is the actual AS-path taken. On the minus side, this rule has 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 tunnel endpoint address associated with it. Packets transmitted via the other path cannot be tunneled.

If routers in a non-originating AS combine routes from different received updates into a single update, and the tunnel attributes from the received updates are not identical, then the tunnel attributes must be excluded from the generated update. This prevents an error whereby a route is associated with the wrong tunnel. Likewise if routers in a non-originating AS receive an update with multiple different tunnel attributes, then it must ignore and drop all of the tunnel attributes.

It is important to note that the behavior in the above paragraph must be followed for both legacy routers (i.e. those that do not recognize the tunnel attributes) as well as updated routers. It is the authors' understanding that all routers today, when combining the routes from different received updates into a single update, will in fact drop any unrecognized attributes from the new attribute. If there are routers that do not do this, however, then this draft will produce errors. There is a fix to these errors that involves placing the originating AS number in the Tunnel Address Attribute, and indeed this was the approach taken by the original version of this draft. If it is determined that such legacy routers exist, then we can revert back to the original draft.

5.  IANA Considerations

IANA must issue a new Sub-Type for the Address Specific BGP Extended Communities Attribute.

6.  Security Considerations

If downstream ASes choose to tunnel packets along an AS-path different from the AS-path to the destination prefix, then upstream ASes may not know the AS-path packets are taking. This can violate a security policy whereby certain ASes must be avoided (see Section 4.2 (Non-Originating ASes)).

7. Normative References

Authors' Addresses