idnits 2.17.1 draft-francis-va-tunnels-mpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (February 11, 2009) is 5552 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-francis-intra-va-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: BCP X. Xu 5 Expires: August 15, 2009 Huawei 6 February 11, 2009 8 MPLS Tunnels for Virtual Aggregation 9 draft-francis-va-tunnels-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 August 15, 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The document "FIB Suppression with Virtual Aggregation" 50 [I-D.francis-intra-va] describes how FIB size may be reduced. The 51 latest revision of that draft refers generically to tunnels, and 52 leaves it to other documents to define the usage and signaling 53 methods for specific tunnel types. This document provides those 54 definitions for MPLS Label Switched Paths (LSP), without tag 55 stacking. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 61 2. Tunneling Requirements . . . . . . . . . . . . . . . . . . . . 3 62 3. Tunneling Specification for MPLS . . . . . . . . . . . . . . . 3 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 This document specifies how to use and signal the tunnels required by 71 [I-D.francis-intra-va], "FIB Suppression with Virtual Aggregation", 72 for MPLS. This document is limited to MPLS without tag stacking. 73 This document adopts the terminology of [I-D.francis-intra-va]. This 74 document covers the behavior for both VA routers and legacy 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.francis-intra-va], VA has the following tunnel- 85 related requirements. The requirement numbers here (R1 - R5) are 86 cited by [I-D.francis-intra-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 signal the tunnel information needed by other routers 91 to 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 signal the tunnel information 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 MPLS tunnels defined in 103 this document allow this capability. 104 R5: All routers must be able to forward all tunneled packets. 106 3. Tunneling Specification for MPLS 108 VA utilizes a straight-forward application of MPLS. The tunnels are 109 MPLS Label Switched Paths (LSP), and are signaled using either the 110 Label Distribution Protocol (LDP) [RFC5036]. (Note that usage of 111 RSVP-TE [RFC3209] to signal these tunnels, in particular the 112 scalability of configuring so many tunnels, is for further study.) 113 All routers (VA and legacy alike) must run LDP, as required by R5. A 114 legacy router that cannot run LDP and initiate LSPs terminating at 115 itself cannot participate in a VA domain. 117 Requirements R1 and R2 require that routers initiate tunnels. This 118 is done by importing the full BGP NEXT_HOP address (/32 if IPv4, /128 119 if IPv6) into the IGP (i.e. OSPF [RFC2328]), and initiating 120 Downstream Unsolicited tunnels to all IGP neighbors with the full BGP 121 NEXT_HOP address as the Forwarding Equivalence Class (FEC). 123 Note that in the case of requirement R2, the BGP NEXT_HOP address is 124 that of the remote ASBR, not that of the router that is initiating 125 the LSP (i.e. the local ASBR VA router). Strictly speaking, this is 126 non-standard behavior---normally it is the router owning the FEC 127 address that initiates signaling. Nevertheless routers can employ 128 existing Penultimate Hop Popping (PHP) mechanisms in the data plane 129 for forwarding packets to remote ASBRs. 131 Requirements R3 and R4 should naturally be satisfied through normal 132 MPLS usage. In other words, the LSP to the BGP NEXT_HOP address 133 should automatically be the preferred method to routing the packet 134 towards the BGP NEXT_HOP address. 136 4. IANA Considerations 138 There are no IANA considerations. 140 5. Security Considerations 142 Because this document describes a (near) standard application of 143 intra-domain MPLS, there are no new security considerations beyond 144 those already described in [I-D.francis-intra-va]. 146 6. Normative References 148 [I-D.francis-intra-va] 149 Francis, P., Xu, X., and H. Ballani, "FIB Suppression with 150 Virtual Aggregation", draft-francis-intra-va-00 (work in 151 progress), February 2009. 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, March 1997. 156 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 158 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 159 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 160 Tunnels", RFC 3209, December 2001. 162 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 163 Specification", RFC 5036, October 2007. 165 Authors' Addresses 167 Paul Francis 168 Max Planck Institute for Software Systems 169 Gottlieb-Daimler-Strasse 170 Kaiserslautern 67633 171 Germany 173 Email: francis@mpi-sws.org 175 Xiaohu Xu 176 Huawei Technologies 177 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 178 Beijing, Beijing 100085 179 P.R.China 181 Phone: +86 10 82836073 182 Email: xuxh@huawei.com