idnits 2.17.1 draft-ietf-grow-va-gre-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.grow-va]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2009) is 5379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-00 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW Working Group X. Xu 3 Internet-Draft Huawei 4 Intended status: Informational P. Francis 5 Expires: January 7, 2010 MPI-SWS 6 R. Raszuk 7 Cisco Systems 8 July 06, 2009 10 GRE and IP-in-IP Tunnels for Virtual Aggregation 11 draft-ietf-grow-va-gre-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 7, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The document "FIB Suppression with Virtual Aggregation" [I-D.grow-va] 50 describes how FIB size may be reduced. That draft refers generically 51 to tunnels, and leaves it to other documents to define the tunnel 52 establishment methods for specific tunnel types. This document 53 provides those definitions for GRE and IP-in-IP tunnels. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 59 2. Tunneling Requirements . . . . . . . . . . . . . . . . . . . . 3 60 3. Tunneling Specification for GRE and IP-in-IP . . . . . . . . . 3 61 3.1. Conveying GRE and IP-in-IP tunnel parameters . . . . . . . 5 62 3.1.1. Usage of the RFC5512 Attributes . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document specifies how to signal and use GRE and IP-in-IP 71 tunnels as required by [I-D.grow-va], "FIB Suppression with Virtual 72 Aggregation". This document adopts the terminology of [I-D.grow-va]. 73 This document covers the behavior for both VA routers and legacy 74 routers. 76 1.1. Requirements notation 78 The key words "must", "must NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Tunneling Requirements 84 According to [I-D.grow-va], VA has the following tunnel-related 85 requirements. The requirement numbers here (R1 - R5) are cited by 86 [I-D.grow-va]. 88 R1: Legacy routers and APRs must be able to detunnel packets 89 addressed to themselves at their BGP NEXT_HOP address. They must 90 be able to convey the tunnel parameters needed by other routers to 91 initiate these tunneled packets. 92 R2: Border VA routers must be able to detunnel packets targeted to 93 neighboring remote ASBRs. They must be able to forward these 94 packets to the targeted remote ASBR without doing a FIB lookup. 95 They must be able to convey the tunnel parameters needed by other 96 routers to initiate these tunneled packets. 97 R3: VA routers must be able to initiate tunneled packets targeted 98 to any BGP NEXT_HOP address (i.e. those for APRs, legacy routers, 99 or remote ASBRs). 100 R4: Legacy routers may optionally be able to initiate tunneled 101 packets targeted to any BGP NEXT_HOP address (i.e. those for APRs, 102 legacy routers, or remote ASBRs). The GRE and IP-in-IP tunnels 103 defined in this document do not have this capability. 104 R5: All routers must be able to forward all tunneled packets. 106 3. Tunneling Specification for GRE and IP-in-IP 108 This document distinguishes between the terms "tunnel endpoint", and 109 "tunnel target". The tunnel endpoint is the router that detunnels 110 the packet (i.e. strips out the outer header and forwards the no- 111 longer-tunneled packet). The tunnel target, on the other hand, is 112 the router to which the packet is going. This distinction manifests 113 itself in the case of requirement R2. That is, a local ASBR (border 114 router) is a VA router, and it detunnels packets. The remote ASBR, 115 however, is the router to which the packet is ultimately targeted. 116 Here, the tunnel endpoint is the local ASBR, and the tunnel target is 117 the remote ASBR. 119 The IP address of the outer header for GRE and IP-in-IP tunnels is 120 always addressed to the tunnel endpoint. If the tunnel endpoint and 121 the tunnel target are the same router (as with the case in 122 requirement R1), then the tunnel type may be GRE or IP-in-IP. If the 123 former, then the Key field may or may not be used. 125 If the tunnel endpoint and the tunnel target are different routers 126 (as is the case in requirement R2), then this document specifies two 127 tunneling approaches. One requires the use of GRE, where the Key 128 field is used to identify the tunnel target to the tunnel endpoint. 129 This is called Key-based identification. The other does not require 130 the use of the Key field, and therefore can be either GRE or 131 IP-in-IP. Instead of using the Key field to identify the tunnel 132 target, a distinct destination IP address is used per tunnel target 133 (remote ASBR) to identify the tunnel target to the tunnel endpoint. 134 This is called address-based identification. 136 The following examples clarify these two cases. Assume a local ASBR 137 has two remote ASBR neighbors, with addresses 2.2.2.2 and 3.3.3.3 138 respectively. 140 In the case of Key-based identification, the local ASBR would assign 141 two GRE Key values, one for each remote ASBR neighbor. The local 142 ASBR would advertise it's own IP address (say 10.1.1.1) as the BGP 143 NEXT_HOP. All GRE packets would arrive at 10.1.1.1 (the tunnel 144 endpoint), which would then look at the Key value to determine 145 whether to forward the packet to 2.2.2.2 or 3.3.3.3. Note that no 146 FIB lookup is necessary. 148 In the case of Address-based identification, the local ASBR would be 149 reachable at a block of IP addresses, say 10.1.1/24. The local ASBR 150 would assign one address from the block for each neighbor remote 151 ASBR. For instance, it could assign the address 10.1.1.2 to remote 152 ASBR 2.2.2.2, and assign the address 10.1.1.3 to remote ASBR 3.3.3.3. 153 Likewise, when advertising NLRI reachable through 2.2.2.2, it would 154 advertise a BGP NEXT_HOP of 10.1.1.2. Packets received at the tunnel 155 endpoint 10.1.1.2 would be forwarded to 2.2.2.2 without a FIB lookup. 156 When advertising NLRI reachable through 3.3.3.3, it would advertise a 157 BGP NEXT_HOP of 10.1.1.3. Packets received at the tunnel endpoint 158 10.1.1.3 would be forwarded to 3.3.3.3 without a FIB lookup. 160 3.1. Conveying GRE and IP-in-IP tunnel parameters 162 This document uses two BGP attributes defined in [RFC5512] to convey 163 the parameters necessary for routers to initiate tunneled packets 164 (i.e. requirement R3). The first attribute, the BGP Encapsulation 165 Extended Community (BGPencap-Attribute), is used when the tunnel type 166 is IP-in-IP or GRE without the Key field. The second BGP attribute, 167 the Tunnel Encapsulation Attribute (TEncap-Attribute), is used when 168 the tunnel type is GRE with a Key field. In either case, routers 169 must tunnel packets to the NEXT_HOP address in the BGP update. 171 3.1.1. Usage of the RFC5512 Attributes 173 Legacy routers are defined here as routers that do not do FIB 174 suppression, but do implement RFC5512. Legacy routers must be 175 configured to attach the BGPencap-Attribute to all iBGP updates, and 176 to detunnel packets addressed to the NEXT_HOP address advertised by 177 the legacy router. This satisfies requirement R1 for legacy routers. 179 In the case where VA routers used Key-based identification, the BGP 180 NEXT_HOP must be set to the local ASBR, GRE must be used, and the 181 TEncap-Attribute must be included. The GRE Key field must be set to 182 a value unique for the remote ASBR to which the packet must be 183 delivered. If the Key value for a given remote ASBR is modified, 184 then both the old and new Key values must identify the remote ASBR in 185 received packets until the new iBGP updates are fully disseminated. 186 This satisfies requirement R2. 188 In the case where VA routers use Address-based identification, the 189 router must have a distinct locally assigned address for each 190 neighbor remote ASBR. The BGP NEXT_HOP field is set to this locally 191 assigned address. This also satisfies requirement R2. 193 If the VA router is an APR, then for tunnels associated with the VP 194 route, where the BGP NEXT_HOP is that of the VA router itself, GRE 195 may or may not be used. If it is used, then the APR must have a way 196 to distinguish tunnels targeted at itself from tunnels targeted to a 197 neighbor remote ASBR. Where Key-based identification is used, this 198 can be done by assigning a unique Key value (i.e. one not assigned to 199 a remote ASBR). Where address-based identification is used, this can 200 be done by using a local IP address not assigned to a remote ASBR. 201 This satisfies requirement R1 for VA routers. 203 All VA routers must use the tunnels described in the tunnel 204 attributes to forward packets to resolved BGP NEXT_HOPs (requirement 205 R3). 207 4. IANA Considerations 209 There are no IANA considerations. 211 5. Security Considerations 213 There are no new security considerations beyond those already 214 described in [I-D.grow-va]. 216 6. Normative References 218 [I-D.grow-va] 219 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 220 L. Zhang, "FIB Suppression with Virtual Aggregation", 221 draft-ietf-grow-va-00 (work in progress), May 2009. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC5512] Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and 227 BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. 229 Authors' Addresses 231 Xiaohu Xu 232 Huawei Technologies 233 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 234 Beijing, Beijing 100085 235 P.R.China 237 Phone: +86 10 82836073 238 Email: xuxh@huawei.com 240 Paul Francis 241 Max Planck Institute for Software Systems 242 Gottlieb-Daimler-Strasse 243 Kaiserslautern 67633 244 Germany 246 Phone: +49 631 930 39600 247 Email: francis@mpi-sws.org 248 Robert Raszuk 249 Cisco Systems 250 170 West Tasman Drive 251 San Jose, CA 95134 252 US 254 Email: raszuk@cisco.com