Internet DRAFT - draft-xu-va-tunnels-gre

draft-xu-va-tunnels-gre






Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: BCP                                          P. Francis
Expires: August 15, 2009                                         MPI-SWS
                                                       February 11, 2009


            GRE and IP-in-IP Tunnels for Virtual Aggregation
                     draft-xu-va-tunnels-gre-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
   (http://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.

Abstract

   The document "FIB Suppression with Virtual Aggregation"



Xu & Francis             Expires August 15, 2009                [Page 1]

Internet-Draft               VA GRE Tunnels                February 2009


   [I-D.francis-intra-va] describes how FIB size may be reduced.  The
   latest revision of that draft refers generically to tunnels, and
   leaves it to other documents to define the usage and signaling
   methods for specific tunnel types.  This document provides those
   definitions for GRE and IP-in-IP tunnels.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . . . 3
   2.  Tunneling Requirements  . . . . . . . . . . . . . . . . . . . . 3
   3.  Tunneling Specification for GRE and IP-in-IP  . . . . . . . . . 3
     3.1.  Signaling GRE and IP-in-IP tunnels  . . . . . . . . . . . . 4
       3.1.1.  Syntax of the Address Specific BGP Extended
               Communities Attribute . . . . . . . . . . . . . . . . . 4
       3.1.2.  Usage of the Address Specific BGP Extended
               Communities Attribute . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6





























Xu & Francis             Expires August 15, 2009                [Page 2]

Internet-Draft               VA GRE Tunnels                February 2009


1.  Introduction

   This document specifies how to use and signal the tunnels required by
   [I-D.francis-intra-va], "FIB Suppression with Virtual Aggregation",
   for GRE and IP-in-IP .  This document adopts the terminology of
   [I-D.francis-intra-va].  This document covers the behavior for both
   VA routers and legacy routers.

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.  Tunneling Requirements

   According to [I-D.francis-intra-va], VA has the following tunnel-
   related requirements.  The requirement numbers here (R1 - R5) are
   cited by [I-D.francis-intra-va].

   R1:    Legacy routers and APRs must be able to detunnel packets
      addressed to themselves at their BGP NEXT_HOP address.  They must
      be able to signal the tunnel information needed by other routers
      to initiate these tunneled packets.
   R2:    Border VA routers must be able to detunnel packets targeted to
      neighboring remote ASBRs.  They must be able to forward these
      packets to the targeted remote ASBR without doing a FIB lookup.
      They must be able to signal the tunnel information needed by other
      routers to initiate these tunneled packets.
   R3:    VA routers must be able to initiate tunneled packets targeted
      to any BGP NEXT_HOP address (i.e. those for APRs, legacy routers,
      or remote ASBRs).
   R4:    Legacy routers may optionally be able to initiate tunneled
      packets targeted to any BGP NEXT_HOP address (i.e. those for APRs,
      legacy routers, or remote ASBRs).  The GRE and IP-in-IP tunnels
      defined in this document do not have this capability.
   R5:    All routers must be able to forward all tunneled packets.


3.  Tunneling Specification for GRE and IP-in-IP

   This documents distinguishes between the terms "tunnel endpoint", and
   "tunnel target".  The tunnel endpoint is the router that detunnels
   the packet (i.e. strips out the outer header and forwards the no-
   longer-tunneled packet).  The tunnel target, on the other hand, is
   the BGP NEXT_HOP to which the packet is going.  This distinction
   manifests itself in the case of requirement R2.  That is, a local



Xu & Francis             Expires August 15, 2009                [Page 3]

Internet-Draft               VA GRE Tunnels                February 2009


   ASBR (border router) is a VA router, and it advertises a BGP NEXT_HOP
   of its neighbor remote ASBR.  Here, the tunnel endpoint is the local
   ASBR, and the tunnel target is the remote ASBR.

   The IP address of the outer header for GRE and IP-in-IP tunnels is
   always addressed to the tunnel endpoint.  If the tunnel endpoint and
   the tunnel target are the same router (as with the case in
   requirement R1), then the tunnel type may be GRE or IP-in-IP.  If the
   former, then the Key field may or may not be used.

   If the tunnel endpoint and the tunnel target are different routers
   (as is the case in requirement R2), then GRE must be used.  Further,
   the Key field is set to a value that identifies the tunnel target to
   the tunnel endpoint.  For example, suppose a local ASBR with address
   1.1.1.1 has two remote ASBR neighbors, with addresses 2.2.2.2 and
   3.3.3.3 respectively.  The local ASBR would assign two GRE Key
   values, one for each remote ASBR neighbor.  All GRE packets would
   arrive at 1.1.1.1 (the tunnel endpoint), which would then look at the
   Key value to determine whether to forward the packet to 2.2.2.2 or
   3.3.3.3.  Note that no FIB lookup is necessary.

3.1.  Signaling GRE and IP-in-IP tunnels

   To signal the information necessary for routers to initiate tunneled
   packets (i.e. requirement R3), two BGP attributes are used.  The
   first attribute serves to indicate that the router advertising the
   attribute can receive tunneled packets, and additionally conveys the
   tunnel endpoint address.  The Address Specific BGP Extended
   Communities Attribute for IPv4 and IPv6 is used for this purpose
   ([RFC4360] and [I-D.ietf-l3vpn-v6-ext-communities] respectively).

   The other BGP attribute is used when the tunnel type is GRE, and is
   used to convey the GRE Key value and other GRE parameters.  For this
   purpose, the Tunnel Encapsulation Attribute (TEncap-Attribute)
   defined in [I-D.ietf-softwire-encaps-safi] is used.

3.1.1.  Syntax of the Address Specific BGP Extended Communities
        Attribute

   The value of the high-order octet for the IPv4 type field is 0x41 as
   defined in [RFC4360] and for the IPv6 type field it is 0x40 as
   defined in [I-D.ietf-l3vpn-v6-ext-communities].  The attribute is
   non-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 Endpoint Address.
   If the Global Administrator field is set to all zeros, then the



Xu & Francis             Expires August 15, 2009                [Page 4]

Internet-Draft               VA GRE Tunnels                February 2009


   Tunnel Endpoint Address is the same as the BGP NEXT_HOP address.

   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] is not present, then the
   encapsulation type is assumed to be IP-in-IP.  If the encapsulation
   type is GRE, then the TEncap-Attribute must be present.  It defines
   the parameters associated with the tunnel as specified in
   [I-D.ietf-softwire-encaps-safi].

3.1.2.  Usage of the Address Specific BGP Extended Communities Attribute

   Legacy routers are configured to detunnel IP-in-IP tunnels addressed
   to them.  They must be programmed to attach the Address Specific BGP
   Extended Communities Attribute to all iBGP updates.  The Global
   Administrator field must be set to either all zeros, or to the
   address used as the BGP NEXT_HOP address.  If it is set to all zeros,
   then the Tunnel Endpoint Address is assumed to be the same as the BGP
   NEXT_HOP address.  This satisfies requirement R1 for legacy routers.

   VA routers must include an Address Specific BGP Extended Communities
   Attribute in all iBGP updates.  In all cases where the BGP NEXT_HOP
   is set to the remote ASBR, the Global Administrator field must be an
   address of the VA router itself, GRE must be used, and the TEncap-
   Attribute must be included.  The GRE Key field must be set to a value
   unique for that remote ASBR.  If the Key value for a given remote
   ASBR is modified, then both the old and new Key values must identify
   the remote ASBR in received packets until the new iBGP updates are
   fully disseminated.  This satisfies requirement R2.

   If the VA router is an APR, then for tunnels associated with the VP
   route, where the BGP NEXT_HOP is that of the VA router itself, GRE
   may or may not be used.  If it is used, then the APR must have a way
   to distinguish tunnels targeted at itself from tunnels targeted to a
   neighbor remote ASBR.  This can be done either by assigning a unique
   Key value (i.e. one not assigned to a remote ASBR), or by using no
   Key field at all.  This satisfies requirement R1 for VA routers.

   All VA routers must use the tunnels described in the tunnel
   attributes to forward packets to resolved BGP NEXT_HOPs (requirement
   R3).


4.  IANA Considerations

   There are no IANA considerations.



Xu & Francis             Expires August 15, 2009                [Page 5]

Internet-Draft               VA GRE Tunnels                February 2009


5.  Security Considerations

   There are no new security considerations beyond those already
   described in [I-D.francis-intra-va].


6.  Normative References

   [I-D.francis-intra-va]
              Francis, P., Xu, X., and H. Ballani, "FIB Suppression with
              Virtual Aggregation", draft-francis-intra-va-00 (work in
              progress), February 2009.

   [I-D.ietf-l3vpn-v6-ext-communities]
              Rekhter, Y., "IPv6 Address Specific BGP Extended
              Communities Attribute",
              draft-ietf-l3vpn-v6-ext-communities-01 (work in progress),
              December 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.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.


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 August 15, 2009                [Page 6]

Internet-Draft               VA GRE Tunnels                February 2009


   Paul Francis
   Max Planck Institute for Software Systems
   Gottlieb-Daimler-Strasse
   Kaiserslautern  67633
   Germany

   Phone: +49 631 930 39600
   Email: francis@mpi-sws.org











































Xu & Francis             Expires August 15, 2009                [Page 7]