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]
