idnits 2.17.1 draft-ietf-grow-va-mpls-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.francis-intra-va]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2009) is 5450 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Francis 3 Internet-Draft MPI-SWS 4 Intended status: Informational X. Xu 5 Expires: November 24, 2009 Huawei 6 May 23, 2009 8 MPLS Tunnels for Virtual Aggregation 9 draft-ietf-grow-va-mpls-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 24, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The document "FIB Suppression with Virtual Aggregation" 48 [I-D.francis-intra-va] describes how FIB size may be reduced. The 49 latest revision of that draft refers generically to tunnels, and 50 leaves it to other documents to define the usage and signaling 51 methods for specific tunnel types. This document provides those 52 definitions for MPLS Label Switched Paths (LSP), without tag 53 stacking. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 59 1.2. Changes from Previous Versions . . . . . . . . . . . . . . 3 60 2. Tunneling Requirements . . . . . . . . . . . . . . . . . . . . 3 61 3. Tunneling Specification for MPLS . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 This document specifies how to use and signal the tunnels required by 70 [I-D.francis-intra-va], "FIB Suppression with Virtual Aggregation", 71 for MPLS. This document is limited to MPLS without tag stacking. 72 This document adopts the terminology of [I-D.francis-intra-va]. This 73 document covers the behavior for both VA routers and legacy routers. 75 1.1. Requirements notation 77 The key words "must", "must NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 1.2. Changes from Previous Versions 83 This document was previously published as 84 draft-francis-va-tunnels-mpls-00. No substantive changes were made 85 from that revision. 87 2. Tunneling Requirements 89 According to [I-D.francis-intra-va], VA has the following tunnel- 90 related requirements. The requirement numbers here (R1 - R5) are 91 cited by [I-D.francis-intra-va]. 93 R1: Legacy routers and APRs must be able to detunnel packets 94 addressed to themselves at their BGP NEXT_HOP address. They must 95 be able to signal the tunnel information needed by other routers 96 to initiate these tunneled packets. 97 R2: Border VA routers must be able to detunnel packets targeted to 98 neighboring remote ASBRs. They must be able to forward these 99 packets to the targeted remote ASBR without doing a FIB lookup. 100 They must be able to signal the tunnel information needed by other 101 routers to initiate these tunneled packets. 102 R3: VA routers must be able to initiate tunneled packets targeted 103 to any BGP NEXT_HOP address (i.e. those for APRs, legacy routers, 104 or remote ASBRs). 105 R4: Legacy routers may optionally be able to initiate tunneled 106 packets targeted to any BGP NEXT_HOP address (i.e. those for APRs, 107 legacy routers, or remote ASBRs). The MPLS tunnels defined in 108 this document allow this capability. 109 R5: All routers must be able to forward all tunneled packets. 111 3. Tunneling Specification for MPLS 113 VA utilizes a straight-forward application of MPLS. The tunnels are 114 MPLS Label Switched Paths (LSP), and are signaled using either the 115 Label Distribution Protocol (LDP) [RFC5036]. (Note that usage of 116 RSVP-TE [RFC3209] to signal these tunnels, in particular the 117 scalability of configuring so many tunnels, is for further study.) 118 All routers (VA and legacy alike) must run LDP, as required by R5. A 119 legacy router that cannot run LDP and initiate LSPs terminating at 120 itself cannot participate in a VA domain. 122 Requirements R1 and R2 require that routers initiate tunnels. This 123 is done by importing the full BGP NEXT_HOP address (/32 if IPv4, /128 124 if IPv6) into the IGP (i.e. OSPF [RFC2328]), and initiating 125 Downstream Unsolicited tunnels to all IGP neighbors with the full BGP 126 NEXT_HOP address as the Forwarding Equivalence Class (FEC). 128 Note that in the case of requirement R2, the BGP NEXT_HOP address is 129 that of the remote ASBR, not that of the router that is initiating 130 the LSP (i.e. the local ASBR VA router). Strictly speaking, this is 131 non-standard behavior---normally it is the router owning the FEC 132 address that initiates signaling. Nevertheless routers can employ 133 existing Penultimate Hop Popping (PHP) mechanisms in the data plane 134 for forwarding packets to remote ASBRs. 136 Requirements R3 and R4 should naturally be satisfied through normal 137 MPLS usage. In other words, the LSP to the BGP NEXT_HOP address 138 should automatically be the preferred method to routing the packet 139 towards the BGP NEXT_HOP address. 141 4. IANA Considerations 143 There are no IANA considerations. 145 5. Security Considerations 147 Because this document describes a (near) standard application of 148 intra-domain MPLS, there are no new security considerations beyond 149 those already described in [I-D.francis-intra-va]. 151 6. Normative References 153 [I-D.francis-intra-va] 154 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 155 L. Zhang, "FIB Suppression with Virtual Aggregation", 156 draft-francis-intra-va-01 (work in progress), April 2009. 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 163 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 164 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 165 Tunnels", RFC 3209, December 2001. 167 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 168 Specification", RFC 5036, October 2007. 170 Authors' Addresses 172 Paul Francis 173 Max Planck Institute for Software Systems 174 Gottlieb-Daimler-Strasse 175 Kaiserslautern 67633 176 Germany 178 Email: francis@mpi-sws.org 180 Xiaohu Xu 181 Huawei Technologies 182 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 183 Beijing, Beijing 100085 184 P.R.China 186 Phone: +86 10 82836073 187 Email: xuxh@huawei.com