[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

GROW Working Group                                                 X. Xu
Internet-Draft                                                    Huawei
Intended status: Informational                                P. Francis
Expires: January 7, 2010                                         MPI-SWS
                                                               R. Raszuk
                                                           Cisco Systems
                                                           July 06, 2009


            GRE and IP-in-IP Tunnels for Virtual Aggregation
                     draft-ietf-grow-va-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 January 7, 2010.

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.






Xu, et al.               Expires January 7, 2010                [Page 1]


Internet-Draft               VA GRE Tunnels                    July 2009


Abstract

   The document "FIB Suppression with Virtual Aggregation" [I-D.grow-va]
   describes how FIB size may be reduced.  That draft refers generically
   to tunnels, and leaves it to other documents to define the tunnel
   establishment 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.  Conveying GRE and IP-in-IP tunnel parameters  . . . . . . . 5
       3.1.1.  Usage of the RFC5512 Attributes . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6






























Xu, et al.               Expires January 7, 2010                [Page 2]


Internet-Draft               VA GRE Tunnels                    July 2009


1.  Introduction

   This document specifies how to signal and use GRE and IP-in-IP
   tunnels as required by [I-D.grow-va], "FIB Suppression with Virtual
   Aggregation".  This document adopts the terminology of [I-D.grow-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.grow-va], VA has the following tunnel-related
   requirements.  The requirement numbers here (R1 - R5) are cited by
   [I-D.grow-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 convey the tunnel parameters 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 convey the tunnel parameters 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 document 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 router to which the packet is going.  This distinction manifests
   itself in the case of requirement R2.  That is, a local ASBR (border



Xu, et al.               Expires January 7, 2010                [Page 3]


Internet-Draft               VA GRE Tunnels                    July 2009


   router) is a VA router, and it detunnels packets.  The remote ASBR,
   however, is the router to which the packet is ultimately targeted.
   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 this document specifies two
   tunneling approaches.  One requires the use of GRE, where the Key
   field is used to identify the tunnel target to the tunnel endpoint.
   This is called Key-based identification.  The other does not require
   the use of the Key field, and therefore can be either GRE or
   IP-in-IP.  Instead of using the Key field to identify the tunnel
   target, a distinct destination IP address is used per tunnel target
   (remote ASBR) to identify the tunnel target to the tunnel endpoint.
   This is called address-based identification.

   The following examples clarify these two cases.  Assume a local ASBR
   has two remote ASBR neighbors, with addresses 2.2.2.2 and 3.3.3.3
   respectively.

   In the case of Key-based identification, the local ASBR would assign
   two GRE Key values, one for each remote ASBR neighbor.  The local
   ASBR would advertise it's own IP address (say 10.1.1.1) as the BGP
   NEXT_HOP.  All GRE packets would arrive at 10.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.

   In the case of Address-based identification, the local ASBR would be
   reachable at a block of IP addresses, say 10.1.1/24.  The local ASBR
   would assign one address from the block for each neighbor remote
   ASBR.  For instance, it could assign the address 10.1.1.2 to remote
   ASBR 2.2.2.2, and assign the address 10.1.1.3 to remote ASBR 3.3.3.3.
   Likewise, when advertising NLRI reachable through 2.2.2.2, it would
   advertise a BGP NEXT_HOP of 10.1.1.2.  Packets received at the tunnel
   endpoint 10.1.1.2 would be forwarded to 2.2.2.2 without a FIB lookup.
   When advertising NLRI reachable through 3.3.3.3, it would advertise a
   BGP NEXT_HOP of 10.1.1.3.  Packets received at the tunnel endpoint
   10.1.1.3 would be forwarded to 3.3.3.3 without a FIB lookup.






Xu, et al.               Expires January 7, 2010                [Page 4]


Internet-Draft               VA GRE Tunnels                    July 2009


3.1.  Conveying GRE and IP-in-IP tunnel parameters

   This document uses two BGP attributes defined in [RFC5512] to convey
   the parameters necessary for routers to initiate tunneled packets
   (i.e. requirement R3).  The first attribute, the BGP Encapsulation
   Extended Community (BGPencap-Attribute), is used when the tunnel type
   is IP-in-IP or GRE without the Key field.  The second BGP attribute,
   the Tunnel Encapsulation Attribute (TEncap-Attribute), is used when
   the tunnel type is GRE with a Key field.  In either case, routers
   must tunnel packets to the NEXT_HOP address in the BGP update.

3.1.1.  Usage of the RFC5512 Attributes

   Legacy routers are defined here as routers that do not do FIB
   suppression, but do implement RFC5512.  Legacy routers must be
   configured to attach the BGPencap-Attribute to all iBGP updates, and
   to detunnel packets addressed to the NEXT_HOP address advertised by
   the legacy router.  This satisfies requirement R1 for legacy routers.

   In the case where VA routers used Key-based identification, the BGP
   NEXT_HOP must be set to the local ASBR, GRE must be used, and the
   TEncap-Attribute must be included.  The GRE Key field must be set to
   a value unique for the remote ASBR to which the packet must be
   delivered.  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.

   In the case where VA routers use Address-based identification, the
   router must have a distinct locally assigned address for each
   neighbor remote ASBR.  The BGP NEXT_HOP field is set to this locally
   assigned address.  This also 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.  Where Key-based identification is used, this
   can be done by assigning a unique Key value (i.e. one not assigned to
   a remote ASBR).  Where address-based identification is used, this can
   be done by using a local IP address not assigned to a remote ASBR.
   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).





Xu, et al.               Expires January 7, 2010                [Page 5]


Internet-Draft               VA GRE Tunnels                    July 2009


4.  IANA Considerations

   There are no IANA considerations.


5.  Security Considerations

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


6.  Normative References

   [I-D.grow-va]
              Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
              L. Zhang, "FIB Suppression with Virtual Aggregation",
              draft-ietf-grow-va-00 (work in progress), May 2009.

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

   [RFC5512]  Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
              BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.


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


   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, et al.               Expires January 7, 2010                [Page 6]


Internet-Draft               VA GRE Tunnels                    July 2009


   Robert Raszuk
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email: raszuk@cisco.com












































Xu, et al.               Expires January 7, 2010                [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/