Internet DRAFT - draft-xu-idr-tunnel

draft-xu-idr-tunnel






Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: Standards Track                              P. Francis
Expires: April 29, 2009                                       Cornell U.
                                                        October 26, 2008


                        Tunnel Endpoints in BGP
                       draft-xu-idr-tunnel-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 29, 2009.

Abstract

   Virtual Aggregation (VA) is a mechanism for shrinking the size of the
   DFZ FIB in routers [I-D.francis-idr-intra-va].  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



Xu & Francis             Expires April 29, 2009                 [Page 1]

Internet-Draft             BGP Tunnel Endpoint              October 2008


   source and destination.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . . . 4
   2.  Endpoint Address Sub-TLV Definition . . . . . . . . . . . . . . 4
   3.  Usage of the TE-Attribute with an Endpoint Address Sub-TLV  . . 4
     3.1.  Originating AS  . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Non-Originating ASes  . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9



































Xu & Francis             Expires April 29, 2009                 [Page 2]

Internet-Draft             BGP Tunnel Endpoint              October 2008


1.  Introduction

   Virtual Aggregation (VA) [I-D.francis-idr-intra-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 [I-D.ietf-softwire-encaps-safi] to encode the tunnel
   information.  However, whereas [I-D.ietf-softwire-encaps-safi]
   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 [I-D.ietf-softwire-encaps-safi].  Its
   purpose, as defined in [I-D.ietf-softwire-encaps-safi], 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
   [I-D.ietf-softwire-encaps-safi] is only within the set of routers
   that do not change the NEXT_HOP field.



Xu & Francis             Expires April 29, 2009                 [Page 3]

Internet-Draft             BGP Tunnel Endpoint              October 2008


   This draft extends the use of the TE-Attribute so that it can be
   passed from AS to AS in normal BGP reachability updates.

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


2.  Endpoint Address Sub-TLV Definition

   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:

           +---------------------------------------------------------+
           | Address Family Identifier (2 octets)                    |
           +---------------------------------------------------------+
           | Reserved  (1 octet)                                     |
           +---------------------------------------------------------+
           | Length of Autonomous System Number (1 octet)            |
           +---------------------------------------------------------+
           | Autonomous System Number (Variable)                     |
           +---------------------------------------------------------+
           | Endpoint Address (variable)                             |
           +---------------------------------------------------------+

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


3.  Usage of the TE-Attribute with an Endpoint Address Sub-TLV

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

3.1.  Originating AS

   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.



Xu & Francis             Expires April 29, 2009                 [Page 4]

Internet-Draft             BGP Tunnel Endpoint              October 2008


   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



Xu & Francis             Expires April 29, 2009                 [Page 5]

Internet-Draft             BGP Tunnel Endpoint              October 2008


   limited encapsulation types to be able to select an encapsulation
   type that works for it.)

3.2.  Non-Originating ASes

   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:

   1.  The AS_PATH to the tunnel endpoint matches the AS path to the
       reachable prefix.
   2.  The AS_PATH advertised by the AS, for all NLRI for which a tunnel
       is used, matches that of the tunnel.
   3.  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.
   4.  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.





Xu & Francis             Expires April 29, 2009                 [Page 6]

Internet-Draft             BGP Tunnel Endpoint              October 2008


4.  IANA Considerations

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


5.  Security Considerations

   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.


6.  Normative References

   [I-D.francis-idr-intra-va]
              Francis, P., Xu, X., and H. Ballani, "FIB Suppression with
              Virtual Aggregation and Default Routes",
              draft-francis-idr-intra-va-01 (work in progress),
              September 2008.

   [I-D.ietf-softwire-encaps-safi]
              Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
              BGP Tunnel Encapsulation Attribute",
              draft-ietf-softwire-encaps-safi-03 (work in progress),
              June 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Authors' Addresses

   Xiaohu Xu
   Huawei Technologies
   No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
   Beijing, Beijing  100085
   P.R.China

   Phone: +86 10 82836073
   Email: xuxh@huawei.com










Xu & Francis             Expires April 29, 2009                 [Page 7]

Internet-Draft             BGP Tunnel Endpoint              October 2008


   Paul Francis
   Cornell University
   4108 Upson Hall
   Ithaca, NY  14853
   US

   Phone: +1 607 255 9223
   Email: francis@cs.cornell.edu











































Xu & Francis             Expires April 29, 2009                 [Page 8]

Internet-Draft             BGP Tunnel Endpoint              October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Xu & Francis             Expires April 29, 2009                 [Page 9]