Network Working Group P. Francis Internet-Draft MPI-SWS Intended status: BCP X. Xu Expires: August 15, 2009 Huawei February 11, 2009 MPLS Tunnels for Virtual Aggregation draft-francis-va-tunnels-mpls-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 August 15, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The document "FIB Suppression with Virtual Aggregation" Francis & Xu Expires August 15, 2009 [Page 1] Internet-Draft VA MPLS Tunnels February 2009 [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for MPLS Label Switched Paths (LSP), without tag stacking. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Tunneling Requirements . . . . . . . . . . . . . . . . . . . . 3 3. Tunneling Specification for MPLS . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Francis & Xu Expires August 15, 2009 [Page 2] Internet-Draft VA MPLS Tunnels February 2009 1. Introduction This document specifies how to use and signal the tunnels required by [I-D.francis-intra-va], "FIB Suppression with Virtual Aggregation", for MPLS. This document is limited to MPLS without tag stacking. This document adopts the terminology of [I-D.francis-intra-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.francis-intra-va], VA has the following tunnel- related requirements. The requirement numbers here (R1 - R5) are cited by [I-D.francis-intra-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 signal the tunnel information 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 signal the tunnel information 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 MPLS tunnels defined in this document allow this capability. R5: All routers must be able to forward all tunneled packets. 3. Tunneling Specification for MPLS VA utilizes a straight-forward application of MPLS. The tunnels are MPLS Label Switched Paths (LSP), and are signaled using either the Label Distribution Protocol (LDP) [RFC5036]. (Note that usage of RSVP-TE [RFC3209] to signal these tunnels, in particular the scalability of configuring so many tunnels, is for further study.) All routers (VA and legacy alike) must run LDP, as required by R5. A Francis & Xu Expires August 15, 2009 [Page 3] Internet-Draft VA MPLS Tunnels February 2009 legacy router that cannot run LDP and initiate LSPs terminating at itself cannot participate in a VA domain. Requirements R1 and R2 require that routers initiate tunnels. This is done by importing the full BGP NEXT_HOP address (/32 if IPv4, /128 if IPv6) into the IGP (i.e. OSPF [RFC2328]), and initiating Downstream Unsolicited tunnels to all IGP neighbors with the full BGP NEXT_HOP address as the Forwarding Equivalence Class (FEC). Note that in the case of requirement R2, the BGP NEXT_HOP address is that of the remote ASBR, not that of the router that is initiating the LSP (i.e. the local ASBR VA router). Strictly speaking, this is non-standard behavior---normally it is the router owning the FEC address that initiates signaling. Nevertheless routers can employ existing Penultimate Hop Popping (PHP) mechanisms in the data plane for forwarding packets to remote ASBRs. Requirements R3 and R4 should naturally be satisfied through normal MPLS usage. In other words, the LSP to the BGP NEXT_HOP address should automatically be the preferred method to routing the packet towards the BGP NEXT_HOP address. 4. IANA Considerations There are no IANA considerations. 5. Security Considerations Because this document describes a (near) standard application of intra-domain MPLS, there are no new security considerations beyond those already described in [I-D.francis-intra-va]. 6. Normative References [I-D.francis-intra-va] Francis, P., Xu, X., and H. Ballani, "FIB Suppression with Virtual Aggregation", draft-francis-intra-va-00 (work in progress), February 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Francis & Xu Expires August 15, 2009 [Page 4] Internet-Draft VA MPLS Tunnels February 2009 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. Authors' Addresses Paul Francis Max Planck Institute for Software Systems Gottlieb-Daimler-Strasse Kaiserslautern 67633 Germany Email: francis@mpi-sws.org 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 Francis & Xu Expires August 15, 2009 [Page 5]