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/ |