--- 1/draft-ietf-mpls-seamless-mpls-04.txt 2014-01-13 13:14:33.134922532 -0800 +++ 2/draft-ietf-mpls-seamless-mpls-05.txt 2014-01-13 13:14:33.206924327 -0800 @@ -1,24 +1,24 @@ MPLS Working Group N. Leymann, Ed. Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: January 17, 2014 Orange +Expires: July 16, 2014 Orange C. Filsfils M. Konstantynowicz, Ed. Cisco Systems D. Steinberg Steinberg Consulting - July 16, 2013 + January 12, 2014 Seamless MPLS Architecture - draft-ietf-mpls-seamless-mpls-04 + draft-ietf-mpls-seamless-mpls-05 Abstract This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service @@ -38,25 +38,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 17, 2014. + This Internet-Draft will expire on July 16, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -64,78 +64,78 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 - 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9 + 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 - 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 + 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 - 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 13 - 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 - 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15 + 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 - 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 16 + 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. General Network Topology . . . . . . . . . . . . . . 17 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18 - 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 18 - 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 19 + 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19 + 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 + 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20 - 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 20 - 5.1.8. Network Availability . . . . . . . . . . . . . . . . 21 - 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 21 - 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 22 + 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 21 + 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 + 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 22 + 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent - Convergence . . . . . . . . . . . . . . . . . . . 22 - 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 23 + Convergence . . . . . . . . . . . . . . . . . . . 23 + 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 5.1.8.5. Assessing loss of connectivity upon any failure . 24 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29 - 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 29 + 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30 5.2.1. Control and Data Plane State for Deployment Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30 - 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 30 + 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33 - 5.2.1.5. Numerical application for use case #1 . . . . . . 33 - 5.2.1.6. Numerical application for use case #2 . . . . . . 34 + 5.2.1.5. Numerical application for use case #1 . . . . . . 34 + 5.2.1.6. Numerical application for use case #2 . . . . . . 35 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction MPLS as a mature and well known technology is widely deployed in today's core and aggregation/metro area networks. Many metro area networks are already based on MPLS delivering Ethernet services to residential and business customers. Until now those deployments are usually done in different domains; e.g. core and metro area networks are handled as separate MPLS domains. @@ -240,27 +240,30 @@ points which can be virtually everywhere in the network. This enables network and service providers with a flexible service and service creation. Service creation can be done based on the existing requirements without the needs for dedicated service creation areas on fixed locations. With the flexibility of Seamless MPLS the service creation can be done anywhere in the network and easily moved between different locations. 2.1. Why Seamless MPLS - Multiple SP plan to deploy networks with 10k to 100k MPLS nodes. - This is typically at least one order of magnitude higher than typical - deployments and may require a new architecture. Multiple options are - possible and it makes sense for the industry (both vendors and SP) to - restrict the options in order to ease the first deployments (e.g. - restrict the number of options to implement and/or scales for - vendors, reduce interoperability and debugging issues for SP). + Multiple Service Providers plan to deploy networks with 10k to 100k + MPLS nodes, with varying levels of MPLS LSP connectivity between + those nodes - sparse-mesh in access, partial-mesh in aggregation and + full-mesh in core. This is typically at least one order of magnitude + higher than current deployments and may require a new architecture. + Multiple options are possible and it makes sense for the industry + (both vendors and SP) to restrict the options in order to ease the + first deployments (e.g. restrict the number of options to implement + and/or scales for vendors, reduce interoperability and debugging + issues for SP). Many aggregation networks are already deploying MPLS but are limited to the use of MPLS per aggregation area. Those MPLS based aggregation domains are connected to a core network running MPLS as well. Nevertheless most of the services are not limited to an aggregation domain but running between several aggregation domains crossing the core network. In the past it was necessary to provide connectivity between the different domains and the core on a per service level and not based on MPLS (e.g. by deploying native IP- Routing or Ethernet based technologies between aggregation and core). @@ -285,32 +288,31 @@ | Aggregation | | Core | | Aggregation | | Domain #1 +---------+ Domain +---------+ Domain #2 | | MPLS | ^ | MPLS | ^ | MPLS | +--------------+ | +--------------+ | +--------------+ | | +------ service specific ------+ configuration Figure 1: Service Specific Configurations - One of the main motivations of Seamless MPLS is to get rid of - services specific configurations between the different MPLS islands. - Seamless MPLS connects all MPLS domains on the MPLS transport layer - providing a single transport layer for all services - independent of - the service itself. The Seamless MPLS architecture therefore - decuples the service and transport layer and integrates access, - aggregation and core into a single platform. One of the big - advantages is that problems on the transport layer only need to be - solved once (and the solutions are available to all services). With - Seamless MPLS it is not necessary to use service specific - configurations on intermediate nodes; all services can be deployed in - an end to end manner. + One of the main motivations of Seamless MPLS is to get rid of service + specific configurations between the different MPLS islands. Seamless + MPLS connects all MPLS domains on the MPLS transport layer providing + a single transport layer for all services - independent of the + service itself. The Seamless MPLS architecture therefore decuples + the service and transport layer and integrates access, aggregation + and core into a single platform. One of the big advantages is that + problems on the transport layer only need to be solved once (and the + solutions are available to all services). With Seamless MPLS it is + not necessary to use service specific configurations on intermediate + nodes; all services can be deployed in an end to end manner. 2.2. Use Case #1 2.2.1. Description In most cases at least residential and business services need to be supported by a network. This section describes a Seamless MPLS use case which supports such a scenario. The use case includes point to point services for business customers as well as typical service creation for residential customers. @@ -1052,21 +1056,21 @@ is encoded as a hierarchy of FIB entry B pointing to a FIB entry I pointing to a FIB entry 0. BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical dataplane with the concept of a BGP Path-List. A BGP path-list may be abstracted as a set of primary multipath nhops and a backup nhop. When the primary set is empty, packets destined to the BGP destinations are rerouted via the backup nhop. For complete description of BGP-PIC technology and its applicability - please refer to [BGP-PIC]. + please refer to [BGP-PIC] and [ABR-FRR]. Hierarchical data plane and BGP-PIC are very simple technologies to operate. Their applicability to any topology, any routing policy and any BGP unicast address family allows router vendors to enable this behavior by default. 5.1.8.4. BGP Egress Node FRR BGP egress node FRR is a Fast ReRoute solution and hence relies on local protection and the precomputation and preinstallation of the @@ -1304,31 +1308,31 @@ More specifically, [RFC6571] plays a key role in the Seamless MPLS architecture as it describes simple design guidelines which determiniscally ensure LFA coverage for any link and node in the aggregation regions of the network. This is key as it provides for a simple <50msec protection for the vast majority of the node and link failures (>90% of the IGP/BGP3107 footprint at least). If the guidelines cannot be met, then either the designer will rely on (1) augmenting native LFA coverage with remote LFA - [I-D.draft-ietf-rtgwg-remote-lfa], or (2) augmenting native LFA - coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP - convergence. The first option provides an automatic and fairly - simple sub-50msec protection as LFA without introducing any - additional protocols. The second option provides the same sub-50msec - protection as LFA, but introduces additional RSVP LSPs. The thrid - option optimizes for sub-50msec protection, but implies a more - complex operational model. The fourth option optimizes for simple - operation but only provides <1 sec protection. Up to each designer - to arbitrate between these three options versus the possibility to - engineer the topology for native LFA protection. + [I-D.ietf-rtgwg-remote-lfa], or (2) augmenting native LFA coverage + with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP convergence. + The first option provides an automatic and fairly simple sub-50msec + protection as LFA without introducing any additional protocols. The + second option provides the same sub-50msec protection as LFA, but + introduces additional RSVP LSPs. The thrid option optimizes for sub- + 50msec protection, but implies a more complex operational model. The + fourth option optimizes for simple operation but only provides <1 sec + protection. Up to each designer to arbitrate between these three + options versus the possibility to engineer the topology for native + LFA protection. A similar choice involves protection against ABR node failure and L3VPN PE node failure. The designer can either use BGP PIC or BGP egress node FRR. Up to each designer to asssess the trade-off between the valuation of sub-50msec instead of sub-1sec versus additional operational considerations related to BGP egress node FRR. 5.1.8.7. Conclusion The Seamless MPLS architecture illustrated in deployment case study 1 @@ -1649,25 +1656,25 @@ 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node failure, MPLS World Congress 2009", . - [ACM01] , , , , "Archieving sub-second IGP convergence in large IP - networks, ACM SIGCOMM Computer Communication Review, v.35 - n.3", July 2005. + [ACM01] , , , and , "Archieving sub-second IGP convergence in + large IP networks, ACM SIGCOMM Computer Communication + Review, v.35 n.3", July 2005. - [BGP-PIC] , "BGP PIC, Technical Report", November 2007. + [BGP-PIC] "BGP PIC, Technical Report", November 2007. [I-D.bashandy-bgp-edge-node-frr] Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP FRR Protection against Edge Node Failure", draft-bashandy- bgp-edge-node-frr-03 (work in progress), July 2012. [I-D.bashandy-bgp-frr-mirror-table] Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR Protection against Edge Node Failure Using Table Mirroring with Context Labels", draft-bashandy-bgp-frr-mirror- @@ -1687,36 +1694,39 @@ [I-D.bashandy-isis-bgp-edge-node-frr] Bashandy, A., "IS-IS Extension for BGP FRR Protection against Edge Node Failure", draft-bashandy-isis-bgp-edge- node-frr-01 (work in progress), September 2012. [I-D.bashandy-mpls-ldp-bgp-frr] Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- bgp-frr-00 (work in progress), March 2012. - [I-D.draft-ietf-rtgwg-remote-lfa] - , . - [I-D.ietf-karp-routing-tcp-analysis] - , . + . [I-D.ietf-mpls-ldp-dod] Beckhaus, T., Decraene, B., Tiruveedhula, K., Konstantynowicz, M., and L. Martini, "LDP Downstream-on- Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work in progress), July 2013. + [I-D.ietf-rtgwg-bgp-pic] + . + + [I-D.ietf-rtgwg-remote-lfa] + . + [I-D.minto-2547-egress-node-fast-protection] - Jeganathan, J. and H. Gredler, "2547 egress PE Fast - Failure Protection", draft-minto-2547-egress-node-fast- - protection-01 (work in progress), October 2012. + Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress + PE Fast Failure Protection", draft-minto-2547-egress-node- + fast-protection-02 (work in progress), July 2013. [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS 2006 Conference", . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. @@ -1728,34 +1738,36 @@ for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. - [RFC5920] , . + [RFC5920] . - [RFC6571] , . + [RFC6571] . + + [RFC7032] . Authors' Addresses + Nicolai Leymann (editor) Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 DE Phone: +49 30 8353-92761 Email: n.leymann@telekom.de - Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux cedex 9 92794 FR Email: bruno.decraene@orange.com Clarence Filsfils Cisco Systems