draft-ietf-mpls-seamless-mpls-05.txt   draft-ietf-mpls-seamless-mpls-06.txt 
MPLS Working Group N. Leymann, Ed. MPLS Working Group N. Leymann, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational B. Decraene Intended status: Informational B. Decraene
Expires: July 16, 2014 Orange Expires: August 18, 2014 Orange
C. Filsfils C. Filsfils
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
Cisco Systems Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
January 12, 2014 February 14, 2014
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-05 draft-ietf-mpls-seamless-mpls-06
Abstract Abstract
This documents describes an architecture which can be used to extend This documents describes an architecture which can be used to extend
MPLS networks to integrate access and aggregation networks into a MPLS networks to integrate access and aggregation networks into a
single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is
based on existing and well known protocols. It provides a highly based on existing and well known protocols. It provides a highly
flexible and a scalable architecture and the possibility to integrate flexible and a scalable architecture and the possibility to integrate
100.000 of nodes. The separation of the service and transport plane 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 is one of the key elements; Seamless MPLS provides end to end service
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 16, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. General Network Topology . . . . . . . . . . . . . . 17 5.1.2. General Network Topology . . . . . . . . . . . . . . 18
5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 5.1.3. Hierarchy based on recursive BGP labeled route lookup 19
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21
5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 21 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 22
5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 22 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
Convergence . . . . . . . . . . . . . . . . . . . 23 Convergence . . . . . . . . . . . . . . . . . . . 24
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24
5.1.8.5. Assessing loss of connectivity upon any failure . 24 5.1.8.5. Assessing loss of connectivity upon any failure . 25
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31
5.2.1. Control and Data Plane State for Deployment Scenario 5.2.1. Control and Data Plane State for Deployment Scenario
#1 . . . . . . . . . . . . . . . . . . . . . . . . . 30 #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34
5.2.1.5. Numerical application for use case #1 . . . . . . 34 5.2.1.5. Numerical application for use case #1 . . . . . . 35
5.2.1.6. Numerical application for use case #2 . . . . . . 35 5.2.1.6. Numerical application for use case #2 . . . . . . 35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
MPLS as a mature and well known technology is widely deployed in MPLS as a mature and well known technology is widely deployed in
today's core and aggregation/metro area networks. Many metro area today's core and aggregation/metro area networks. Many metro area
networks are already based on MPLS delivering Ethernet services to networks are already based on MPLS delivering Ethernet services to
residential and business customers. Until now those deployments are residential and business customers. Until now those deployments are
usually done in different domains; e.g. core and metro area networks usually done in different domains; e.g. core and metro area networks
are handled as separate MPLS domains. are handled as separate MPLS domains.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
MPLS transport layer all systems are clearly identified using the MPLS transport layer all systems are clearly identified using the
loopback address of the system. An ingress node must be able to loopback address of the system. An ingress node must be able to
establish a service to an arbitrary egress system by using the establish a service to an arbitrary egress system by using the
corresponding MPLS transport label corresponding MPLS transport label
2.2.2. Typical Numbers 2.2.2. Typical Numbers
Table 1 shows typical numbers which are expected for Use Case #1 Table 1 shows typical numbers which are expected for Use Case #1
(access node). (access node).
+-------------------+---------------+ +--------------------+---------------+
| Parameter | Typical Value | | Parameter | Typical Value |
+-------------------+---------------+ +--------------------+---------------+
| IGP Control Plane | 2 | | IGP RIB Entries | 2 |
| IP FIB | 2 | | IP FIB Entries | 2 |
| LDP Control Plane | 200 | | LDP LIB Entries | 200 |
| LDP FIB | 200 | | MPLS NHLFE Entries | 200 |
| BGP Control Plane | 0 | | MPLS ILM Entries | 0 |
| BGP FIB | 0 | | BGP RIB Entries | 0 |
+-------------------+---------------+ | BGP FIB Entries | 0 |
+--------------------+---------------+
Table 1: Use Case #1: Typical Numbers for Access Node Table 1: Use Case #1: Typical Numbers for Access Node
2.3. Use Case #2 2.3. Use Case #2
2.3.1. Description 2.3.1. Description
In most cases, residential, wholesales and business services need to In most cases, residential, wholesales and business services need to
be supported by the network. be supported by the network.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
o Number of Access Nodes: 40.000 o Number of Access Nodes: 40.000
2.3.2. Typical Numbers 2.3.2. Typical Numbers
Table 2 shows typical numbers which are expected for Use Case #2 for Table 2 shows typical numbers which are expected for Use Case #2 for
the purpose of establishing the transport LSPs. They do not take the purpose of establishing the transport LSPs. They do not take
into account the services built in addition. (e.g. 6PE will require into account the services built in addition. (e.g. 6PE will require
additional IPv6 routes). additional IPv6 routes).
+-------------------+---------------+ +--------------------+---------------+
| Parameter | Typical Value | | Parameter | Typical Value |
+-------------------+---------------+ +--------------------+---------------+
| IGP Control Plane | 2 | | IGP RIB Entries | 2 |
| IP FIB | 2 | | IP FIB Entries | 2 |
| LDP Control Plane | 1000 | | LDP LIB Entries | 1,400 |
| LDP FIB | 1000 | | MPLS NHLFE Entries | 1,400 |
+-------------------+---------------+ | MPLS ILM Entries | 1,400 |
+--------------------+---------------+
Table 2: Use Case #2: Typical Numbers for Access Node Table 2: Use Case #2: Typical Numbers for Access Node
3. Requirements 3. Requirements
The following section describes the overall requirements which need The following section describes the overall requirements which need
to be fulfilled by the Seamless MPLS architecture. Beside the to be fulfilled by the Seamless MPLS architecture. Beside the
general requirements of the architecture itself there are also general requirements of the architecture itself there are also
certain requirements which are related to the different network certain requirements which are related to the different network
nodes. nodes.
skipping to change at page 15, line 7 skipping to change at page 15, line 7
o Switch Fabric o Switch Fabric
o Routing Processor o Routing Processor
A change from an active component to a standby component SHOULD A change from an active component to a standby component SHOULD
happen without effecting customers traffic. The Influence of happen without effecting customers traffic. The Influence of
customer traffic MUST be as low as possible. customer traffic MUST be as low as possible.
3.4. Scalability 3.4. Scalability
The network must be highly scalable. As a minimum requirement the The network must be highly scalable. Based on the use cases
described in Sections 2.2 and 2.3, as a minimum requirement the
following scalability figures should be met: following scalability figures should be met:
o Number of aggregation domains: 100 o Number of aggregation domains: 100
o Number of backbone nodes: 1.000 o Number of backbone nodes: 1.000
o Number of aggregation nodes: 10.000 o Number of aggregation nodes: 10.000
o Number of access nodes: 100.000 o Number of access nodes: 100.000
skipping to change at page 16, line 37 skipping to change at page 16, line 40
The intra-domain routing within each of the MPLS domains (i.e. The intra-domain routing within each of the MPLS domains (i.e.
aggregation domains and core) SHOULD utilize standard IGP protocols aggregation domains and core) SHOULD utilize standard IGP protocols
like OSPF or ISIS. By definition, each of these domains is small like OSPF or ISIS. By definition, each of these domains is small
enough so that there are no relevant scaling limits within each IGP enough so that there are no relevant scaling limits within each IGP
domain, given well-known state-of-the-art IGP design principles and domain, given well-known state-of-the-art IGP design principles and
recent router technology. recent router technology.
The intra-domain MPLS LSP setup and label distribution SHOULD utilize The intra-domain MPLS LSP setup and label distribution SHOULD utilize
standard protocols like LDP or RSVP. standard protocols like LDP or RSVP.
Note that this document describes the design based on LDP, LDP
Downstream-on-Demand and labeled BGP due to the higher degree of out-
of-the-box automation and operational simplicity as well as
compatibility with the existing backbone and backhaul designs &
deployments which use LDP and not RSVP-TE. It also assumes
relatively simple MPLS implementations on access nodes. The protocol
choices for the design described in this document have been driven by
the actual SP deployments. Design based on the hierarchy of RSVP-TE
LSPs may be an alternative, but has not been considered in this
document.
4.5. Inter-Domain Routing 4.5. Inter-Domain Routing
The inter-domain routing is responsible for establishing connectivity The inter-domain routing is responsible for establishing connectivity
between and across all MPLS domains. The inter-domain routing SHOULD between and across all MPLS domains. The inter-domain routing SHOULD
establish a routing and forwarding hierarchy in order to achieve the establish a routing and forwarding hierarchy in order to achieve the
scaling goals of seamless MPLS. Note that the IP aggregation usually scaling goals of seamless MPLS. Note that the IP aggregation usually
performed between region (IGP areas/AS) in IP routing does not work performed between region (IGP areas/AS) in IP routing does not work
for MPLS as MPLS is not capable of aggregating FEC (because MPLS for MPLS as MPLS is not capable of aggregating FEC (because MPLS
forwarding use an exact match lookup, while IP uses longest match). forwarding use an exact match lookup, while IP uses longest match).
Therefore it is RECOMMENDED to utilize protocols that support Therefore it is RECOMMENDED to utilize protocols that support
indirect next-hops ( e.g. using BGP to carry MPLS label information indirect next-hops ( e.g. using BGP to carry MPLS label information
[RFC3107] ). [RFC3107] ). The mechanism for the LSP forwarding hierarchy is
described in Section 5.3.
4.6. Access 4.6. Access
Compared to the aggregation and core parts of the Seamless MPLS Compared to the aggregation and core parts of the Seamless MPLS
network the access part is special in two respects: network the access part is special in two respects:
o The number of ndes in the access is at least one order of o The number of nodes in the access is at least one order of
magnitude higher than in any other part of the network. magnitude higher than in any other part of the network.
o Because of the large quantity of access nodes, the cost of these o Because of the large quantity of access nodes, the cost of these
nodes is extremly relevant for the overall costs of the entire nodes is extremely relevant for the overall costs of the entire
network, i.e. acess nodes are very cost sensitive. network, i.e. acess nodes are very cost sensitive.
This makes it desirable to design the architecture such that the AN This makes it desirable to design the architecture such that the AN
functionality can be kept as simple as possible. This should always functionality can be kept as simple as possible. This should always
be kept in mind when evalulating different seamless MPLS be kept in mind when evaluating different seamless MPLS
architectures. The goal is to limit both the number of different architectures. The goal is to limit both the number of different
protocols needed on the AN as well as the scale to which each protocols needed on the AN as well as the scale to which each
protocol must perform to the absolute minimum. protocol must perform to the absolute minimum.
5. Deployment Scenarios 5. Deployment Scenarios
This section describes the deployment scenarios based on the use This section describes the deployment scenarios based on the use
cases and the generic architecture above. cases and the generic architecture above.
5.1. Deployment Scenario #1 5.1. Deployment Scenario #1
skipping to change at page 18, line 43 skipping to change at page 19, line 9
The ABRs on the core side have redundant connections to a pair of LSR The ABRs on the core side have redundant connections to a pair of LSR
routers. routers.
The LSR pair is also connected via a direct link. The LSR pair is also connected via a direct link.
The core LSR are connected to other core LSR in a partly meshed The core LSR are connected to other core LSR in a partly meshed
topology so that there are disjunct, redundant paths from each LSR to topology so that there are disjunct, redundant paths from each LSR to
each other LSR. each other LSR.
5.1.3. Hierarchy 5.1.3. Hierarchy based on recursive BGP labeled route lookup
As explained before, hierarchy is the key to a scalable seamless MPLS Inline with the explanation in section 4.5, LSP hierarchy is key to a
architecture. The hierarchy in this implementation is achieved by scalable seamless MPLS architecture.
forming different MPLS domains for aggregation domains and core,
where within each of these domains a fairly common MPLS deployment
using ISIS as intradomain link-state routing protocol and using LDP
for MPLS label distribution is used.
These MPLS domains are mapped to ISIS areas as follows: Aggregation The LSP hierarchy in this design is achieved by:
domains are mapped to ISIS L1 areas. The core is configured as ISIS
L2. The border routers connecting aggregation and core are ISIS L1L2
and are referred to as ABRs. From a technical and operational point
of view these ABRs are part of the core, althought they also belong
to the respective aggregation domain purely from a routing protocol
point of view.
For the inter-domain routing BGP with MPLS labels is o Forming separate MPLS domains for aggregation and core areas.
deployed[RFC3107].
o Intra-domain LSP connectivity provided by combination of IS-IS (as
the intra-domain link-state routing protocol) and LDP (used for
MPLS label distribution for intra-domain LSPs).
o Inter-domain LSP connectivity provided by labeled BGP [RFC3107]
(used for MPLS label distribution for inter-domain LSP FECs) and
relying on IS-IS and LDP for intra-domain LSP connectivity between
the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS
core notes are not carrying the labeled BGP routes.
The aggregation and core MPLS domains are mapped to IS-IS areas as
follows: Aggregation domains are mapped to IS-IS L1 areas. The core
is configured as IS-IS L2. The border routers connecting aggregation
and core are IS-IS L1L2 and are referred to as ABRs. From a
technical and operational point of view these ABRs are part of the
core, although they also belong to the respective aggregation domain
purely from a routing protocol point of view.
5.1.4. Intra-Area Routing 5.1.4. Intra-Area Routing
5.1.4.1. Core 5.1.4.1. Core
The core uses ISIS L2 to distribute routing information for the The core uses ISIS L2 to distribute routing information for the
loopback addresses of all core nodes. The border routers (ABR) that loopback addresses of all core nodes. The border routers (ABR) that
connect to the aggregation domains are also part of the respective connect to the aggregation domains are also part of the respective
aggregation ISIS L1 area and hence ISIS L1L2. aggregation ISIS L1 area and hence ISIS L1L2.
skipping to change at page 31, line 15 skipping to change at page 31, line 37
Let's take the following assumptions: Let's take the following assumptions:
o Aggregation equipments are equally spread across aggregation o Aggregation equipments are equally spread across aggregation
routing domains routing domains
o the number of IGP links is three times the number of IGP nodes o the number of IGP links is three times the number of IGP nodes
o the number of IGP prefixes is five times the number of IGP nodes o the number of IGP prefixes is five times the number of IGP nodes
(links prefixes + 2 loopbacks) (links prefixes + 2 loopbacks)
o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC o Each Access Node needs to have up to 1,000 (1k) LSPs. This is
driven by the expected AN access line capacity, and a sum of LSPs
required for connectivity to PE routers providing edge services as
well as a remote ANs. 100 LSPs per AN (10% of total) are FECs
which are outside of their routing domain. Those 100 remote FEC which are outside of their routing domain. Those 100 remote FEC
are the same for all Access Nodes of a given AGN. are the same for all Access Nodes of a given AGN.
The following sections roughly evaluate the scalability, both in The following sections roughly evaluate the scalability, both in
absolute numbers and relatively with the number of Access Node which absolute numbers and relatively with the number of Access Node which
is the biggest scalability factor. is the biggest scalability factor.
5.2.1.2. Core Domain 5.2.1.2. Core Domain
The IGP & LDP core domain are not affected by the number of access The IGP & LDP core domain are not affected by the number of access
skipping to change at page 31, line 47 skipping to change at page 32, line 24
#Core ~ o(1) #Core ~ o(1)
Core TN FIBs grows linearly with the number of node in the core Core TN FIBs grows linearly with the number of node in the core
domain. In other word, they are not affected by AGN and AN nodes: domain. In other word, they are not affected by AGN and AN nodes:
Core TN: Core TN:
IP FIB : 5*#Core ~ o(1) IP FIB : 5*#Core ~ o(1)
MPLS LFIB : #Core ~ o(1) MPLS ILM (LFIB) : #Core ~ o(1)
BGP carries all AN routes which is significant. However, all AN BGP carries all AN routes which is significant. However, all AN
routes are only needed in the control plane, possibly in a dedicated routes are only needed in the control plane, possibly in a dedicated
BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the
forwarding plane. The number of routes (100k) is smaller than the forwarding plane. The number of routes (100k) is smaller than the
number of number of routes in the Internet (300k and rising) or in number of number of routes in the Internet (300k and rising) or in
major VPN SP (>500k and rising) so the target can be handled with major VPN SP (>500k and rising) so the target can be handled with
current implementations. In addition, AN routes are internal routes current implementations. In addition, AN routes are internal routes
whose churn and instability is smaller and more under control than whose churn and instability is smaller and more under control than
external routes. external routes.
skipping to change at page 32, line 24 skipping to change at page 32, line 50
path : 2*#AN ~ o(2n) path : 2*#AN ~ o(2n)
ABR handles both the core and aggregations routes. They do not ABR handles both the core and aggregations routes. They do not
depend on the total number of AN nodes, but only on the number of AN depend on the total number of AN nodes, but only on the number of AN
in their aggregation domain. in their aggregation domain.
ABR: ABR:
IP FIB : 5*#Core + (5*#AGN + #AN) / #Area ~ o(#AN /#Area) IP FIB : 5*#Core + (5*#AGN + #AN) / #Area ~ o(#AN /#Area)
MPLS LFIB : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)
5.2.1.3. Aggregation Domain 5.2.1.3. Aggregation Domain
In the aggregation domain, IGP & LDP are not affected by the number In the aggregation domain, IGP & LDP are not affected by the number
of access nodes outside of their domain. They are not affected by of access nodes outside of their domain. They are not affected by
the total number of AN nodes: the total number of AN nodes:
IGP: IGP:
node : #AGN / #Area ~ o(1) node : #AGN / #Area ~ o(1)
skipping to change at page 33, line 18 skipping to change at page 33, line 41
aggregation area, plus the number of inter domain LSP required by the aggregation area, plus the number of inter domain LSP required by the
AN attached to them. They do not depend on the total number of AN AN attached to them. They do not depend on the total number of AN
nodes. In the BGP control plane, AGN also needs to handle all the AN nodes. In the BGP control plane, AGN also needs to handle all the AN
routes. routes.
AGN: AGN:
IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/ IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/
#Area) #Area)
MPLS LFIB : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / #Area) MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN /
#Area)
AN FIBs grows with its connectivity requirement. They do not depend AN FIBs grows with its connectivity requirement. They do not depend
on the number of AN, AGN, SN or any others nodes. on the number of AN, AGN, SN or any others nodes.
AN: AN:
IP RIB : 1 ~ o(1) IP RIB : 1 ~ o(1)
MPLS LIB : 1k ~ o(1) MPLS LIB : 1k ~ o(1)
IP FIB : 1 ~ o(1) IP FIB : 1 ~ o(1)
MPLS LFIB : 1k ~ o(1) MPLS ILM (LFIB) : 1k ~ o(1)
5.2.1.4. Summary 5.2.1.4. Summary
AN requirements are kept minimal. BGP is not required and the size AN requirements are kept to a minimum. BGP is not required on ANs
of their FIB is limited to their own connectivity requirements. and the size of their FIB is driven only by their own connectivity
requirements. In the FIB scale analysis described in sections
5.2.1.x, it was assumed that any single AN will need no more than
1,000 LSPs. This assumption is based on the expected AN access line
capacity and LSPs required for connectivity to PE routers providing
edge services as well as a sparse mesh of connectivity between ANs.
In the core area, IGP and LDP are not affected by the node in the In the core area, IGP and LDP are not affected by the nodes in the
aggregation domains. In particular they do not grow with the number aggregation domains. In particular they do not grow with the number
of AGN or AN. of AGNs or ANs.
In the aggregation areas, IGP and LDP are affected by the number of In the aggregation areas, IGP and LDP are affected by the number of
core nodes and the number of AGN and AN in their area. They are not core nodes and the number of AGNs and ANs in their area. They are
affected by the total number of AGN or AN in the seamless MPLS not affected by the total number of AGNs or ANs in the seamless MPLS
domain. domain.
No FIB of any node is required to handle the total number of AGN or No FIB of any node is required to handle the total number of AGNs or
AN in the seamless MPLS domain. In other word, the number of AGN and ANs in the Seamless MPLS domain. In other words, the number of AGNs
AN in the seamless MPLS domain is not limited, if the number of areas and ANs in the Seamless MPLS domain is not a limiting factor, and the
can grow accordingly. The main limitation is the MPLS connectivity design can be scaled by growing the number of areas. The main
requirements on the AN, i.e. mainly the number of LSP needed on the limitation is the MPLS connectivity requirements on the AN, i.e.
AN. Another limitation may be the number of different LSP needed by mainly the number of LSP needed per AN. Another limitation may be
AN attached or behind an AGN. However, given foreseen deployments the number of different LSPs required by ANs attached to specific
and current AGN capabilities, this is not expected to be a AGN. However, given the foreseen deployments and current AGN
limitation. capabilities, this is not expected to be a limiting factor.
In the control plane, BGP will typically handle all AN routes. This In the control plane, BGP will typically handle all AN routes. This
is significant but target deployments are well under current is expected to be substantial, but again the target deployment scale
equipments capacities. In addition, if required, additional are well within the capabilities of current equipment . In addition,
techniques could be used to improve this scalability, based on the if required, additional techniques could be used to improve the
experience gained with scaling BGP/MPLS VPN (e.g. route partitioning scalability, based on the experience gained with scaling BGP/MPLS VPN
between RR planes, route filtering (static or dynamic with ORF or (e.g. route partitioning between RR planes, route filtering (static
route refresh) between AN and on AGN to improve AGN scalability. or dynamic with ORF or route refresh) between ANs and on AGN to
improve AGN scalability.
5.2.1.5. Numerical application for use case #1 5.2.1.5. Numerical application for use case #1
As a recap, targets for deployment scenario 1 are: As a recap, targets for deployment scenario 1 are:
o Number of Aggregation Domains 100 o Number of Aggregation Domains 100
o Number of Backbone Nodes 1.000 o Number of Backbone Nodes 1.000
o Number of AGgregation Nodes 10.000 o Number of AGgregation Nodes 10.000
o Number of Access Nodes 100.000 o Number of Access Nodes 100.000
This gives the following scaling numbers for each category of nodes: This gives the following scaling numbers for each category of nodes:
o AN IP FIB 1 o AN IP FIB 1
o AN MPLS LFIB 1 000 o AN MPLS ILM (LFIB) 1 000
o AGN IP FIB 2 600 o AGN IP FIB 2 600
o AGN MPLS LFIB 2 200 o AGN MPLS ILM (LFIB) 2 200
o ABR IP FIB 7 600 o ABR IP FIB 7 600
o ABR MPLS LFIB 2 100 o ABR MPLS ILM (LFIB) 2 100
o TN IP FIB 5 000 o TN IP FIB 5 000
o TN MPLS LFIB 1 000 o TN MPLS ILM (LFIB) 1 000
o RR BGP NLRI 100 000 o RR BGP NLRI 100 000
o RR BGP paths 200 000 o RR BGP paths 200 000
5.2.1.6. Numerical application for use case #2 5.2.1.6. Numerical application for use case #2
As a recap, targets for deployment scenario 1 are: As a recap, targets for deployment scenario 1 are:
o Number of Aggregation Domains 30 o Number of Aggregation Domains 30
skipping to change at page 35, line 21 skipping to change at page 36, line 7
o Number of Backbone Nodes 150 o Number of Backbone Nodes 150
o Number of AGgregation Nodes 1.500 o Number of AGgregation Nodes 1.500
o Number of Access Nodes 40.000 o Number of Access Nodes 40.000
This gives the following scaling numbers for each category of nodes: This gives the following scaling numbers for each category of nodes:
o AN IP FIB 1 o AN IP FIB 1
o AN MPLS LFIB 1 000 o AN MPLS ILM (LFIB) 1 000
o AGN IP FIB 1 700 o AGN IP FIB 1 700
o AGN MPLS LFIB 1 800 o AGN MPLS ILM (LFIB) 1 800
o ABR IP FIB 3 700 o ABR IP FIB 3 700
o ABR MPLS LFIB 1 600 o ABR MPLS ILM (LFIB) 1 600
o TN IP FIB 750 o TN IP FIB 750
o TN MPLS LFIB 150 o TN MPLS ILM (LFIB) 150
o RR BGP NLRI 40 000 o RR BGP NLRI 40 000
o RR BGP paths 80 000 o RR BGP paths 80 000
6. Acknowledgements 6. Acknowledgements
Many people contributed to this document. The authors would like to Many people contributed to this document. The authors would like to
thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas,
Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon
 End of changes. 47 change blocks. 
101 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/