--- 1/draft-ietf-mpls-seamless-mpls-02.txt 2013-05-13 15:14:09.903597037 +0100 +++ 2/draft-ietf-mpls-seamless-mpls-03.txt 2013-05-13 15:14:09.979598833 +0100 @@ -1,144 +1,144 @@ MPLS Working Group N. Leymann, Ed. Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: April 25, 2013 France Telecom +Expires: November 14, 2013 France Telecom C. Filsfils - M. Konstantynowicz + M. Konstantynowicz, Ed. Cisco Systems D. Steinberg Steinberg Consulting - October 22, 2012 + May 13, 2013 Seamless MPLS Architecture - draft-ietf-mpls-seamless-mpls-02 + draft-ietf-mpls-seamless-mpls-03 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 independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 25, 2013. + This Internet-Draft will expire on November 14, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 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 . . . . . . . . . . . . . . . . . . . 10 + 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 - 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12 - 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 + 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 - 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 15 - 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 16 - 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 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 + 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 + 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15 + 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 + 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 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 . . . . . . . . . . . . . . . . . . 19 - 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18 + 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . 21 + 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 + 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 - 5.1.8. Network Availability . . . . . . . . . . . . . . . . . 23 + 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 - 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24 - 5.1.8.3. Hierarchical Dataplane and BGP Prefix - Independent Convergence . . . . . . . . . . . . . 24 - 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 25 + 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 + 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent + Convergence . . . . . . . . . . . . . . . . . . . 24 + 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 5.1.8.5. Assessing loss of connectivity upon any failure . 25 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 - 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 30 + 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 - 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 31 - 5.2.1. Control and Data Plane State for Deployment - Scenario #1 . . . . . . . . . . . . . . . . . . . . . 31 - 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 31 - 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 32 - 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 33 + 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 + 5.2.1. Control and Data Plane State for Deployment Scenario + #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 + 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 + 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 - 5.2.1.5. Numerical application for use case #1 . . . . . . 35 + 5.2.1.5. Numerical application for use case #1 . . . . . . 34 5.2.1.6. Numerical application for use case #2 . . . . . . 35 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8.1. Access Network Security . . . . . . . . . . . . . . . . . 37 8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37 - 8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 38 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 + 8.3. Control Plane Security . . . . . . . . . . . . . . . . . 38 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 9.2. Informative References . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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. @@ -209,23 +209,23 @@ o Use Case: Describes a typical network including service creation points in order to describe the requirments, typical numbers etc. which need to be taken into account when applying the Seamless MPLS architecture. 2. Motivation MPLS is deployed in core and aggregation network for several years and provides a mature and stable basis for large networks. In - addition MPLS is already used in access networks, e.g. such as mobile - or DSL backhaul. Today MPLS as technology is being used on two - different layers: + addition MPLS is already used in access networks, e.g. such as + mobile or DSL backhaul. Today MPLS as technology is being used on + two different layers: o the Transport Layer and o the Service Layer (e.g. for MPLS VPNs) In both cases the protocols and the encapsulation are identical but the use of MPLS is different especially concerning the signalling, the control plane, the provisioning, the scalability and the frequency of updates. On the service layer only service specific information is exchanged; every service can potentially deploy it's @@ -1045,22 +1042,22 @@ delay and a linear FIB update [ACM01]. The initial delay could conservatively be assumed to be 260msec: 50msec to detect failures with BFD (most failures would be detected faster with loss of light for example or with faster BFD timers), 50msec to throttle the LSP generation, 150msec to throttle the SPF computation (making sure than all the required LSP's are received even in case of SRLG failures) and 10msec for shortest-path-first tree computation. - Assuming 250usec per update (conservative), this allows for (1000- - 260)/0.250= 2960 prefixes update within a second following the + Assuming 250usec per update (conservative), this allows for + (1000-260)/0.250= 2960 prefixes update within a second following the outage. More precisely, this allows for 2960 important IGP prefixes updates. Important prefixes are automatically classified by the router implementation through simple heuristic (/32 is more important than non-/32). The number of IGP important routes (loopbacks) in deployment case study 1 is much smaller than 2960, and hence sub-second IGP convergence is conservative. IGP convergence is a simple technology for the operator provided that @@ -1512,22 +1508,22 @@ In the aggregation domain, IGP & LDP are not affected by the number of access nodes outside of their domain. They are not affected by the total number of AN nodes: IGP: node : #AGN / #Area ~ o(1) links : 3*#AGN / #Area ~ o(1) - IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN - *5/ #Area) + IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5 + / #Area) + + 1 loopback per core node + one aggregate per area + 5 prefixes per AGN in the area + 1 prefix per AN in the area. LDP FEC: Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) + + 1 loopback per core node + 1 loopback per AGN & AN node in the area. @@ -1763,118 +1757,117 @@ access locations with lower physical security, designer could also consider using: o different crypto keys for use in authentication procedures for these locations. o stricter network protection mechanisms including DoS protection, interface and session flap dampening. 9. References + 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". + failure, MPLS World Congress 2009", . - [ACM01] "Archieving sub-second IGP convergence in large IP + [ACM01] , , , , "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.draft-bashandy-bgp-edge-node-frr-03] - "". + , . [I-D.draft-bashandy-bgp-frr-mirror-table-00] - "". + , . [I-D.draft-ietf-rtgwg-remote-lfa-00] - "". + , . [I-D.draft-minto-2547-egress-node-fast-protection-00] - "". + , . [I-D.filsfils-rtgwg-lfa-applicability] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "LFA - applicability in SP networks", - draft-filsfils-rtgwg-lfa-applicability-00 (work in - progress), March 2010. + applicability in SP networks", draft-filsfils-rtgwg-lfa- + applicability-00 (work in progress), March 2010. [I-D.ietf-bfd-v4v6-1hop] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), January 2010. [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-03 (work - in progress), August 2012. + Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-06 (work + in progress), May 2013. [I-D.kothari-henderickx-l2vpn-vpls-multihoming] Kothari, B., Kompella, K., Henderickx, W., and F. Balus, "BGP based Multi-homing in Virtual Private LAN Service", draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work in progress), July 2009. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", - draft-narten-iana-considerations-rfc2434bis-09 (work in - progress), March 2008. + IANA Considerations Section in RFCs", draft-narten-iana- + considerations-rfc2434bis-09 (work in progress), March + 2008. [I-D.raggarwa-mac-vpn] Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and - F. Balus, "BGP MPLS Based MAC VPN", - draft-raggarwa-mac-vpn-01 (work in progress), June 2010. + F. Balus, "BGP MPLS Based MAC VPN", draft-raggarwa-mac- + vpn-01 (work in progress), June 2010. [I-D.sajassi-l2vpn-rvpls-bgp] Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and - S. Boutros, "Routed VPLS using BGP", - draft-sajassi-l2vpn-rvpls-bgp-01 (work in progress), - July 2010. + S. Boutros, "Routed VPLS using BGP", draft-sajassi-l2vpn- + rvpls-bgp-01 (work in progress), July 2010. - [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in - MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS - 2006 Conference". + [PE-FRR] Le Roux, J.L., Decraene, B., and Z. Ahmad, "Fast Reroute + in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS + 2006 Conference", . - [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and F. Ansari, "Overview of IP Multicast in a Multi- Protocol Label Switching (MPLS) Environment", RFC 3353, August 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, - July 2003. + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute - Extensions to RSVP-TE for LSP Tunnels", RFC 4090, - May 2005. + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May + 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. @@ -1895,45 +1888,36 @@ Winterfeldtstrasse 21 Berlin 10781 DE Phone: +49 30 8353-92761 Email: n.leymann@telekom.de Bruno Decraene France Telecom 38-40 rue du General Leclerc - Issy Moulineaux cedex 9, 92794 + Issy Moulineaux cedex 9 92794 FR - Phone: - Fax: - Email: bruno.decraene@orange-ftgroup.com - URI: + Email: bruno.decraene@orange.com Clarence Filsfils Cisco Systems - Brussels, + Brussels Belgium - Phone: - Fax: Email: cfilsfil@cisco.com - URI: - Maciek Konstantynowicz + Maciek Konstantynowicz (editor) Cisco Systems - London, + London United Kingdom - Phone: - Fax: Email: maciek@cisco.com - URI: Dirk Steinberg Steinberg Consulting Ringstrasse 2 Buchholz 53567 DE Email: dws@steinbergnet.net