draft-ietf-mpls-seamless-mpls-06.txt | draft-ietf-mpls-seamless-mpls-07.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: August 18, 2014 Orange | Expires: December 30, 2014 Orange | |||
C. Filsfils | C. Filsfils | |||
M. Konstantynowicz, Ed. | M. Konstantynowicz, Ed. | |||
Cisco Systems | Cisco Systems | |||
D. Steinberg | D. Steinberg | |||
Steinberg Consulting | Steinberg Consulting | |||
February 14, 2014 | June 28, 2014 | |||
Seamless MPLS Architecture | Seamless MPLS Architecture | |||
draft-ietf-mpls-seamless-mpls-06 | draft-ietf-mpls-seamless-mpls-07 | |||
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 August 18, 2014. | This Internet-Draft will expire on December 30, 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 49 | skipping to change at page 2, line 49 | |||
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 . . . . . . . . . . . . . . . . . . 17 | 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17 | |||
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 | 4.7. Signalling and Label Distribution . . . . . . . . . . . . 17 | |||
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 | 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 | 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 19 | |||
5.1.2. General Network Topology . . . . . . . . . . . . . . 18 | 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.3. Hierarchy based on recursive BGP labeled route lookup 19 | 5.1.2. General Network Topology . . . . . . . . . . . . . . 19 | |||
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19 | 5.1.3. Hierarchy based on recursive BGP labeled route lookup 20 | |||
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19 | 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 21 | |||
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 | 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 21 | |||
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 20 | 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 21 | |||
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 | 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 | 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 22 | |||
5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 22 | 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 22 | |||
5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 | 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 23 | |||
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 | 5.1.8. Network Availability . . . . . . . . . . . . . . . . 24 | |||
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 | 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24 | |||
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 25 | ||||
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent | 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent | |||
Convergence . . . . . . . . . . . . . . . . . . . 24 | Convergence . . . . . . . . . . . . . . . . . . . 25 | |||
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 | 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 26 | |||
5.1.8.5. Assessing loss of connectivity upon any failure . 25 | 5.1.8.5. Assessing loss of connectivity upon any failure . 26 | |||
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 | 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 30 | |||
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 | 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 31 | |||
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 | 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 32 | |||
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 | 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 32 | |||
5.2.1. Control and Data Plane State for Deployment Scenario | 5.2.1. Control and Data Plane State for Deployment Scenarios 32 | |||
#1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 32 | |||
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 | 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 33 | |||
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 | 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 34 | |||
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 | 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 36 | |||
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 | 5.2.1.5. Numerical application for use case #1 . . . . . . 36 | |||
5.2.1.5. Numerical application for use case #1 . . . . . . 35 | 5.2.1.6. Numerical application for use case #2 . . . . . . 37 | |||
5.2.1.6. Numerical application for use case #2 . . . . . . 35 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 | 9.2. Informative References . . . . . . . . . . . . . . . . . 39 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
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 8, line 42 | skipping to change at page 8, line 42 | |||
Node and link failures are handled by rerouting the PWs (based on | Node and link failures are handled by rerouting the PWs (based on | |||
standard mechanisms). End customers (either residential or business | standard mechanisms). End customers (either residential or business | |||
customers) are connected to the access nodes using a native | customers) are connected to the access nodes using a native | |||
technology like Ethernet. The access nodes terminates the PW(s) | technology like Ethernet. The access nodes terminates the PW(s) | |||
carrying the traffic for the end customers. The link between the | carrying the traffic for the end customers. The link between the | |||
access node (AN) and the aggregation node (AGN) is the first MPLS | access node (AN) and the aggregation node (AGN) is the first MPLS | |||
enabled link. | enabled link. | |||
Residential Services: The service creation for all residential | Residential Services: The service creation for all residential | |||
customers connected to the Access Nodes in an aggregation domain | customers connected to the Access Nodes in an aggregation domain | |||
is located on an Service Node connected to the AGN2x. The PW (PW1) | is located on an Service Node connected to the AGN2x. The PW | |||
originated at the AN and terminates at the AGN2. A second PW is | (PW1) originated at the AN and terminates at the AGN2. A second | |||
deployed in the case where redundancy is needed on the AN (the | PW is deployed in the case where redundancy is needed on the AN | |||
figure shows redundancy but this might not be the case for all ANs | (the figure shows redundancy but this might not be the case for | |||
in this Use Case). Additonal PWs can be deployed as well in case | all ANs in this Use Case). Additonal PWs can be deployed as well | |||
more than a single service creation is needed for the residential | in case more than a single service creation is needed for the | |||
service (e.g. one service creation point for Internet access and a | residential service (e.g. one service creation point for Internet | |||
second service creation point for IPTV services). | access and a second service creation point for IPTV services). | |||
Business Sercvices: For business services the use cases shows point | Business Sercvices: For business services the use cases shows point | |||
to point connections between two access nodes. PW2 originates at | to point connections between two access nodes. PW2 originates at | |||
the AN and terminates on the remote AN crossing two aggregation | the AN and terminates on the remote AN crossing two aggregation | |||
areas and the core network. If the access node needs connections | areas and the core network. If the access node needs connections | |||
to several remote ANs the corresponding number of PWs will be | to several remote ANs the corresponding number of PWs will be | |||
originated at the AN. Nevertheless taking the number of ports | originated at the AN. Nevertheless taking the number of ports | |||
available and the number of business customers on a typical access | available and the number of business customers on a typical access | |||
node the number of PWs will be relatively small. | node the number of PWs will be relatively small. | |||
skipping to change at page 9, line 43 | skipping to change at page 9, line 43 | |||
stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is | stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is | |||
used to aggregate traffic from several AGN1x pairs. In this use case | used to aggregate traffic from several AGN1x pairs. In this use case | |||
an aggregation domain is not limited to the use of a single pair of | an aggregation domain is not limited to the use of a single pair of | |||
AGN2x; the deployment of several AGN2 pairs within the domain is also | AGN2x; the deployment of several AGN2 pairs within the domain is also | |||
supported. As design goal for the scalability of the routing and | supported. As design goal for the scalability of the routing and | |||
forwarding within the Seamless MPLS architecture the following | forwarding within the Seamless MPLS architecture the following | |||
numbers are used: | numbers are used: | |||
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 | |||
The access nodes (AN) are dual homed to two different aggregation | The access nodes (AN) are dual homed to two different aggregation | |||
nodes (AGN11 and AGN12) using static routing entries on the AN. The | nodes (AGN11 and AGN12) using static routing entries on the AN. The | |||
ANs are always source or sink nodes for MPLS traffic but not transit | ANs are always source or sink nodes for MPLS traffic but not transit | |||
nodes. This allows a light MPLS implementation in order to reduce | nodes. This allows a light MPLS implementation in order to reduce | |||
the complexity in the AN. The aggregation network consists of two | the complexity in the AN. The aggregation network consists of two | |||
stages with redundant connections between the stages (AGN11 is | stages with redundant connections between the stages (AGN11 is | |||
connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). | connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). | |||
The gateway between the aggregation and core network is realized | The gateway between the aggregation and core network is realized | |||
using the Area Border Routers (ABR). From the perspective of the | using the Area Border Routers (ABR). From the perspective of the | |||
skipping to change at page 15, line 13 | skipping to change at page 15, line 13 | |||
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. Based on the use cases | The network must be highly scalable. Based on the use cases | |||
described in Sections 2.2 and 2.3, as a minimum requirement the | 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 | |||
3.5. Stability | 3.5. Stability | |||
o The platform should be stable under certain circumstances (e.g. | o The platform should be stable under certain circumstances (e.g. | |||
missconfiguration within one area should not cause instability in | missconfiguration within one area should not cause instability in | |||
other areas). | other areas). | |||
o Differentiate between "All Loopbacks and Link addresses should be | o Differentiate between "All Loopbacks and Link addresses should be | |||
ping able from every where." Vs. "Link addresses are not | ping able from every where." Vs. "Link addresses are not | |||
necessary ping able from everywhere". | necessary ping able from everywhere". | |||
skipping to change at page 17, line 39 | skipping to change at page 17, line 39 | |||
nodes is extremely 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 evaluating 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. | |||
4.7. Signalling and Label Distribution | ||||
Following figures show IP/MPLS signaling and label distribution for | ||||
an LSP from AN2 to AN1 (192.0.2.1), detailing the signalling from AN1 | ||||
to AN2 (left to right) and packet forwarding from AN2 to AN1 (right | ||||
to left). It is assumed that Penultimate Hop Popping is used. | ||||
Terminology used in the figures: | ||||
o LDP DoD: LDP Downstream on Demand | ||||
o LDP DU: LDP Downstream Unsolicited | ||||
o BGP LU: BGP Label Unicast (RFC 3107) | ||||
o BGP NH: BGP Next Hop Label LYZi: L=Label, Y= node advertising the | ||||
FEC (G for AGN, B for ABR, A for AN), Z= protocol advertising it | ||||
(B for BGP, L for LDP) | ||||
--------------------------------------------------------------------- | ||||
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 | ||||
LDP DoD -> BGP LU -> BGP LU -> LDP DoD | ||||
Next Hop Self | ||||
192.0.2.1 192.0.2.1 192.0.2.1 192.0.2.1 | ||||
Labels: LAL1 LAB1 LAB2 LAL2 | ||||
BGP NH: AGN1 BGP NH: ABR1 | ||||
Figure 5: MPLS signalling for the AN / edge layer | ||||
--------------------------------------------------------------------- | ||||
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 | ||||
| IS-IS level 2 | IS-IS level 1 -> IS-IS level 2 | | ||||
| LDPDU - LDPDU - LDPDU - LDPDU - LDPDU - LDPDU | | ||||
FEC: AGN1 ABR1 ABR1 | ||||
Label: LGL1 LGL2 LBL1 LBL2 LBL3 LBL4 | ||||
Figure 6: MPLS signalling and IP routing for the core layer | ||||
--------------------------------------------------------------------- | ||||
Static | IS-IS level 2 | IS-IS level 1 | IS-IS level 2 | Static | ||||
Routing Routing | ||||
192.0.2.1 -> 192.0.2/24 -> 192.0.2/20 -> 192.2/20 0/0 | ||||
AGN1 ABR1 ABR1 | ||||
Figure 7: IP routing for the AN / edge layer | ||||
--------------------------------------------------------------------- | ||||
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 | ||||
FEC AN1: LAL1 LAB1 LAB2 LAB2 LAB2 LAB2 LAL2 | ||||
FEC AGN1: LGL2 LBL1 LBL2 LBL3 LBL4 | ||||
/ABR1 | ||||
Figure 8: Forwarding Plane | ||||
--------------------------------------------------------------------- | ||||
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 | |||
Section describing the Seamless MPLS implementation of a large | Section describing the Seamless MPLS implementation of a large | |||
european ISP. | european ISP. | |||
skipping to change at page 18, line 32 | skipping to change at page 19, line 44 | |||
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN | +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN | |||
/ | | /| | | | | | | / | | /| | | | | | | |||
+----+/ +-------+\/ +-------+ +------+ /+------+ | +----+/ +-------+\/ +-------+ +------+ /+------+ | |||
| AN | /\ \/ | | | AN | /\ \/ | | |||
+----+\ +-------+ \+-------+ +------+/\ +------+ | +----+\ +-------+ \+-------+ +------+/\ +------+ | |||
\ | | | | | | \| | | \ | | | | | | \| | | |||
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | |||
| | | | | | | | | | | | | | | | | | |||
+-------+ +-------+ +------+ +------+ | +-------+ +-------+ +------+ +------+ | |||
static route ISIS L1 LDP ISIS L2 LDP | static route ISIS L1 LDP DU ISIS L2 LDP DU | |||
<-Access-><--Aggregation Domain--><---------Core---------> | <-Access-><--Aggregation Domain--><---------Core---------> | |||
Figure 5: Deployment Scenario #1 | Figure 9: Deployment Scenario #1 | |||
As shown in Figure 5, the access nodes (AN) are connected to the | As shown in Figure 9, the access nodes (AN) are connected to the | |||
aggregation network via aggregation nodes called AGN1x, either to a | aggregation network via aggregation nodes called AGN1x, either to a | |||
single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant | single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant | |||
uplinks to a pair of second-level aggregation nodes called AGN2x. | uplinks to a pair of second-level aggregation nodes called AGN2x. | |||
Each aggregation domain is connected to the core via exactly two | Each aggregation domain is connected to the core via exactly two | |||
border routers (ABR) on the core side. There can be multiple AGN2 | border routers (ABR) on the core side. There can be multiple AGN2 | |||
pairs per aggregation domain, but only one ABR pair for each | pairs per aggregation domain, but only one ABR pair for each | |||
aggregation domain. Each of the AGN2 in an AGN2 pair connects to one | aggregation domain. Each of the AGN2 in an AGN2 pair connects to one | |||
of the ABRs in the ABR pair responsible for that aggregation domain. | of the ABRs in the ABR pair responsible for that aggregation domain. | |||
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. | |||
skipping to change at page 19, line 19 | skipping to change at page 20, line 32 | |||
5.1.3. Hierarchy based on recursive BGP labeled route lookup | 5.1.3. Hierarchy based on recursive BGP labeled route lookup | |||
Inline with the explanation in section 4.5, LSP hierarchy is key to a | Inline with the explanation in section 4.5, LSP hierarchy is key to a | |||
scalable seamless MPLS architecture. | scalable seamless MPLS architecture. | |||
The LSP hierarchy in this design is achieved by: | The LSP hierarchy in this design is achieved by: | |||
o Forming separate MPLS domains for aggregation and core areas. | o Forming separate MPLS domains for aggregation and core areas. | |||
o Intra-domain LSP connectivity provided by combination of IS-IS (as | o Intra-domain LSP connectivity provided by combination of IS-IS (as | |||
the intra-domain link-state routing protocol) and LDP (used for | the intra-domain link-state routing protocol) and LDP DU (used for | |||
MPLS label distribution for intra-domain LSPs). | MPLS label distribution for intra-domain LSPs). | |||
o Inter-domain LSP connectivity provided by labeled BGP [RFC3107] | o Inter-domain LSP connectivity provided by labeled BGP [RFC3107] | |||
(used for MPLS label distribution for inter-domain LSP FECs) and | (used for MPLS label distribution for inter-domain LSP FECs) and | |||
relying on IS-IS and LDP for intra-domain LSP connectivity between | relying on IS-IS and LDP DU for intra-domain LSP connectivity | |||
the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS | between the LSR labeled BGP speakers (AGNs and ABRs). Note that | |||
core notes are not carrying the labeled BGP routes. | the MPLS core notes are not carrying the labeled BGP routes. | |||
The aggregation and core MPLS domains are mapped to IS-IS areas as | 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 | follows: Aggregation domains are mapped to IS-IS L1 areas. The core | |||
is configured as IS-IS L2. The border routers connecting aggregation | 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 | 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 | technical and operational point of view these ABRs are part of the | |||
core, although they also belong to the respective aggregation domain | core, although they also belong to the respective aggregation domain | |||
purely from a routing protocol point of view. | 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. | |||
LDP is used to distribute MPLS label binding information for the | LDP DU is used to distribute MPLS label binding information for the | |||
loopback addresses of all core nodes. | loopback addresses of all core nodes. | |||
5.1.4.2. Aggregation | 5.1.4.2. Aggregation | |||
The aggregation domains uses ISIS L1 as intra-domain routing | The aggregation domains uses ISIS L1 as intra-domain routing | |||
protocol. All AGN loopback addresses are carried in ISIS. | protocol. All AGN loopback addresses are carried in ISIS. | |||
As in the core, the aggregation also uses LDP to distribute MPLS | As in the core, the aggregation also uses LDP DU to distribute MPLS | |||
label bindings for the loopback addresses. | label bindings for the loopback addresses. | |||
5.1.5. Access | 5.1.5. Access | |||
Access nodes do not have their own domain or IGP area. Instead, they | Access nodes do not have their own domain or IGP area. Instead, they | |||
directly connect to the AGN1 nodes in the aggregation domain. To | directly connect to the AGN1 nodes in the aggregation domain. To | |||
keep access devices as simple as possible, ANs do not participate in | keep access devices as simple as possible, ANs do not participate in | |||
ISIS. | ISIS. | |||
Instead, each AN has two static default routes pointing to each of | Instead, each AN has two static default routes pointing to each of | |||
skipping to change at page 20, line 31 | skipping to change at page 21, line 48 | |||
The AGN1 MUST have a configured static route to the loopback address | The AGN1 MUST have a configured static route to the loopback address | |||
of each of the ANs it is connected to, because it cannot learn the AN | of each of the ANs it is connected to, because it cannot learn the AN | |||
loopback address in any other way. These static routes have to be | loopback address in any other way. These static routes have to be | |||
monitored and invalidated if necessary using the same techniques as | monitored and invalidated if necessary using the same techniques as | |||
described above for the static default routes on the AN. | described above for the static default routes on the AN. | |||
The AGN1 redistributes these routes into ISIS for intra-domain | The AGN1 redistributes these routes into ISIS for intra-domain | |||
reachability of all AN loopback addresses. | reachability of all AN loopback addresses. | |||
LDP is used for MPLS label distribution between AGN1 and AN. In | LDP DU is used for MPLS label distribution between AGN1 and AN. In | |||
order to keep the AN control plane as lightweight as possible, and to | order to keep the AN control plane as lightweight as possible, and to | |||
avoid the necessity for the AN to store 100.000 MPLS label bindings | avoid the necessity for the AN to store 100.000 MPLS label bindings | |||
for each upstream AGN1 peer, LDP is deployed in downstream-on-demand | for each upstream AGN1 peer, LDP is deployed in downstream-on-demand | |||
(DoD) mode, described below. | (DoD) mode, described below. | |||
To allow the label bindings received via LDP DoD to be installed into | To allow the label bindings received via LDP DoD to be installed into | |||
the LFIB on the AN without having the specific host route to the | the LFIB on the AN without having the specific host route to the | |||
destination loopback address, but only a default route, use of the | destination loopback address, but only a default route, use of the | |||
LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. | LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. | |||
skipping to change at page 21, line 9 | skipping to change at page 22, line 26 | |||
The assumption is that a given AN will only have a limited number of | The assumption is that a given AN will only have a limited number of | |||
services configured to an even more limited number of destinations, | services configured to an even more limited number of destinations, | |||
or egress LER. Instead of learning and storing all label bindings | or egress LER. Instead of learning and storing all label bindings | |||
for all possible loopback addresses within the entire Seamless MPLS | for all possible loopback addresses within the entire Seamless MPLS | |||
network, the AN will use LDP DoD to only request the label bindings | network, the AN will use LDP DoD to only request the label bindings | |||
for the FECs corresponding to the loopback addresses of those egress | for the FECs corresponding to the loopback addresses of those egress | |||
nodes to which it has services configured. | nodes to which it has services configured. | |||
More detailed description of LDP DoD use cases for MPLS access and | More detailed description of LDP DoD use cases for MPLS access and | |||
list of required LDP DoD procedures in the context of Seamless MPLS | list of required LDP DoD procedures in the context of Seamless MPLS | |||
design is included in [I-D.ietf-mpls-ldp-dod]. | design is included in [RFC7032]. | |||
5.1.6. Inter-Area Routing | 5.1.6. Inter-Area Routing | |||
The inter-domain MPLS connectivity from the aggregation domains to | The inter-domain MPLS connectivity from the aggregation domains to | |||
and across the core domain is realized primarily using BGP with MPLS | and across the core domain is realized primarily using BGP with MPLS | |||
labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of | labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of | |||
route leaking from ISIS L2 into L1 is also used. | route leaking from ISIS L2 into L1 is also used. | |||
All ABR and PE nodes in the core are part of the labeled iBGP mesh, | All ABR and PE nodes in the core are part of the labeled iBGP mesh, | |||
which can be either full mesh or based on route reflectors. These | which can be either full mesh or based on route reflectors. These | |||
skipping to change at page 24, line 19 | skipping to change at page 25, line 36 | |||
network. | network. | |||
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence | 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence | |||
In a hierarchical dataplane, the FIB used by the packet processing | In a hierarchical dataplane, the FIB used by the packet processing | |||
engine reflects recursions between the routes. For example, a BGP | engine reflects recursions between the routes. For example, a BGP | |||
route B recursing on IGP route I whose best path is via interface O | route B recursing on IGP route I whose best path is via interface O | |||
is encoded as a hierarchy of FIB entry B pointing to a FIB entry I | is encoded as a hierarchy of FIB entry B pointing to a FIB entry I | |||
pointing to a FIB entry 0. | pointing to a FIB entry 0. | |||
BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical | BGP Prefix Independent Convergence [I-D.rtgwg-bgp-pic] extends the | |||
dataplane with the concept of a BGP Path-List. A BGP path-list may | hierarchical dataplane with the concept of a BGP Path-List. A BGP | |||
be abstracted as a set of primary multipath nhops and a backup nhop. | path-list may be abstracted as a set of primary multipath nhops and a | |||
When the primary set is empty, packets destined to the BGP | backup nhop. When the primary set is empty, packets destined to the | |||
destinations are rerouted via the backup nhop. | BGP destinations are rerouted via the backup nhop. | |||
For complete description of BGP-PIC technology and its applicability | For complete description of BGP-PIC technology and its applicability | |||
please refer to [BGP-PIC] and [ABR-FRR]. | please refer to [I-D.rtgwg-bgp-pic] and [ABR-FRR]. | |||
Hierarchical data plane and BGP-PIC are very simple technologies to | Hierarchical data plane and BGP-PIC are very simple technologies to | |||
operate. Their applicability to any topology, any routing policy and | operate. Their applicability to any topology, any routing policy and | |||
any BGP unicast address family allows router vendors to enable this | any BGP unicast address family allows router vendors to enable this | |||
behavior by default. | behavior by default. | |||
5.1.8.4. BGP Egress Node FRR | 5.1.8.4. BGP Egress Node FRR | |||
BGP egress node FRR is a Fast ReRoute solution and hence relies on | BGP egress node FRR is a Fast ReRoute solution and hence relies on | |||
local protection and the precomputation and preinstallation of the | local protection and the precomputation and preinstallation of the | |||
skipping to change at page 31, line 12 | skipping to change at page 32, line 38 | |||
the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For | the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For | |||
specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. | specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. | |||
Both approaches have their pros and cons, and the choice is left to | Both approaches have their pros and cons, and the choice is left to | |||
each Service Provider or deployment based on the different | each Service Provider or deployment based on the different | |||
requirements. The key point is that the seamless MPLS architecture | requirements. The key point is that the seamless MPLS architecture | |||
can handle fast restoration time, even for ABR failures. | can handle fast restoration time, even for ABR failures. | |||
5.2. Scalability Analysis | 5.2. Scalability Analysis | |||
5.2.1. Control and Data Plane State for Deployment Scenario #1 | 5.2.1. Control and Data Plane State for Deployment Scenarios | |||
5.2.1.1. Introduction | 5.2.1.1. Introduction | |||
Let's call: | Let's call: | |||
o #AN the number of Access Node (AN) in the seamless MPLS domain | o #AN the number of Access Node (AN) in the seamless MPLS domain | |||
o #AGN the number of AGgregation Node (AGN) in the seamless MPLS | o #AGN the number of AGgregation Node (AGN) in the seamless MPLS | |||
domain | domain | |||
skipping to change at page 31, line 37 | skipping to change at page 33, line 15 | |||
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 Each Access Node needs to have up to 1,000 (1k) LSPs. This is | o Each Access Node needs to have up to 1,000 (1k) LSPs. LSP scale | |||
driven by the expected AN access line capacity, and a sum of LSPs | requirement is driven by expected AN access line capacity and the | |||
required for connectivity to PE routers providing edge services as | sum of LSPs required for connectivity to PE routers providing edge | |||
well as a remote ANs. 100 LSPs per AN (10% of total) are FECs | services as well as a remote ANs. Number and type of services | |||
which are outside of their routing domain. Those 100 remote FEC | accessed by the AN has also an impact. Hence it is very service | |||
are the same for all Access Nodes of a given AGN. | specific. Note that if the number of remote PE/LSPs is higher | |||
than the capacity of the AN, some route aggregation scheme can be | ||||
enabled at the service layer, e.g. using RFC7024 for IP VPN. It | ||||
is assumed that 100 LSPs per AN (10% of total) are FECs that are | ||||
outside of their routing domain. Those 100 remote FEC 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 | |||
nodes: | nodes: | |||
IGP: | IGP: | |||
node : #Core ~ o(1) | node : #Core ~ o(1) | |||
links : 3*#Core ~ o(1) | links : 3*#Core ~ o(1) | |||
IP prefixes : 5*#Core ~ o(1) | IP prefixes : 5*#Core + #Area ~ o(1) | |||
LDP FEC: | LDP FEC: | |||
#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 + #Area ~ o(1) | |||
MPLS ILM (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 | |||
skipping to change at page 32, line 48 | skipping to change at page 34, line 31 | |||
NLRI : #AN ~ o(n) | NLRI : #AN ~ o(n) | |||
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 + #Area ~ | |||
o(#AN/#Area) | ||||
MPLS ILM (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) | |||
links : 3*#AGN / #Area ~ o(1) | links : 3*#AGN / #Area ~ o(1) | |||
IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5 | IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN | |||
/ #Area) | *5/ #Area) | |||
+ plus one aggregate per area (because the number of IP | ||||
+ + 1 loopback per core node + one aggregate per area + 5 | prefixes is equal to 1 loopback per core node), plus 5 | |||
prefixes per AGN in the area + 1 prefix per AN in the area. | prefixes per AGN in the area, plus 1 prefix per AN in the | |||
area. | ||||
LDP FEC: | LDP FEC: | |||
Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) | Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) | |||
+ + 1 loopback per core node + 1 loopback per AGN & AN node in | + plus one aggregate per area (because the number of IP | |||
the area. | prefixes is equal to 1 loopback per core node), plus 5 | |||
prefixes per AGN in the area, plus 1 prefix per AN in the | ||||
area. | ||||
AGN FIBs grows with the number of node in the core area, in their | AGN FIBs grows with the number of node in the core area, in their | |||
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 ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / | MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / | |||
#Area) | #Area) | |||
AN FIBs grows with its connectivity requirement. They do not depend | AN FIBs grow with the connectivity requirement of the services. They | |||
on the number of AN, AGN, SN or any others nodes. | do not depend 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 ILM (LFIB) : 1k ~ o(1) | MPLS ILM : 1k ~ o(1) if the AN is used in transit by other ANs | |||
and hence is an LSR (use case #2 having chained AN) | ||||
MPLS ILM : 0 ~ o(1) if the AN is not providing transit to | ||||
others ANs (use case #1 where AN are final leaf) | ||||
MPLS NHLFE : 1k ~ o(1) | ||||
5.2.1.4. Summary | 5.2.1.4. Summary | |||
AN requirements are kept to a minimum. BGP is not required on ANs | AN requirements are kept to a minimum. BGP is not required on ANs | |||
and the size of their FIB is driven only by their own connectivity | and the size of their FIB is driven only by their own connectivity | |||
requirements. In the FIB scale analysis described in sections | 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 | 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 | 1,000 LSPs. This assumption is based on the expected AN access line | |||
capacity and LSPs required for connectivity to PE routers providing | capacity and LSPs required for connectivity to PE routers providing | |||
edge services as well as a sparse mesh of connectivity between ANs. | edge services as well as a sparse mesh of connectivity between ANs. | |||
skipping to change at page 35, line 11 | skipping to change at page 36, line 49 | |||
(e.g. route partitioning between RR planes, route filtering (static | (e.g. route partitioning between RR planes, route filtering (static | |||
or dynamic with ORF or route refresh) between ANs and on AGN to | or dynamic with ORF or route refresh) between ANs and on AGN to | |||
improve AGN scalability. | 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 Access Nodes 100.000 | o Number of AGgregation Nodes 10,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 ILM (LFIB) 1 000 | o AN MPLS ILM 0 | |||
o AGN IP FIB 2 600 | o AN MPLS NHLFE 1,000 | |||
o AGN MPLS ILM (LFIB) 2 200 | o AGN IP FIB 2,600 | |||
o ABR IP FIB 7 600 | o AGN MPLS ILM (LFIB) 2,200 | |||
o ABR MPLS ILM (LFIB) 2 100 | o ABR IP FIB 6,600 | |||
o TN IP FIB 5 000 | o ABR MPLS ILM (LFIB) 2,100 | |||
o TN MPLS ILM (LFIB) 1 000 | o TN IP FIB 5,100 | |||
o RR BGP NLRI 100 000 | o TN MPLS ILM (LFIB) 1,000 | |||
o RR BGP paths 200 000 | o RR BGP NLRI 100,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 | |||
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 ILM (LFIB) 1 000 | o AN MPLS ILM 1,000 | |||
o AGN IP FIB 1 700 | o AN MPLS NHLFE 1,000 | |||
o AGN MPLS ILM (LFIB) 1 800 | o AGN IP FIB 1,763 | |||
o AGN MPLS ILM 1,633 | ||||
o ABR IP FIB 3 700 | o ABR IP FIB 2,363 | |||
o ABR MPLS ILM (LFIB) 1 600 | o ABR MPLS ILM 1,533 | |||
o TN IP FIB 750 | o TN IP FIB 780 | |||
o TN MPLS ILM (LFIB) 150 | o TN MPLS ILM 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, George Swallow, Kireeti Kompella, Yakov Rekhter, Mark | |||
DeLord for their suggestions and review. | Tinka, Curtis Villamizar and Simon DeLord for their suggestions and | |||
review. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
This memo does not include any requests to IANA. | This memo does not include any requests to IANA. | |||
8. Security Considerations | 8. Security Considerations | |||
The Seamless MPLS Architecture is subject to similar security threats | The Seamless MPLS Architecture is subject to similar security threats | |||
as any MPLS LDP deployment. It is recommended that baseline security | as any MPLS LDP deployment. It is recommended that baseline security | |||
measures are considered as described in Security Framework for MPLS | measures are considered as described in Security Framework for MPLS | |||
and GMPLS networks [RFC5920], in the LDP specification RFC5036 | and GMPLS networks [RFC5920], in the LDP specification RFC5036 | |||
[RFC5036] and in [I-D.ietf-karp-routing-tcp-analysis]including | [RFC5036] and in [RFC6952]including ensuring authenticity and | |||
ensuring authenticity and integrity of LDP messages, as well as | integrity of LDP messages, as well as protection against spoofing and | |||
protection against spoofing and Denial of Service attacks. Some | Denial of Service attacks. Some deployments may require increased | |||
deployments may require increased measures of network security if a | measures of network security if a subset of Access Nodes are placed | |||
subset of Access Nodes are placed in locations with lower levels of | in locations with lower levels of physical security e.g. street | |||
physical security e.g. street cabinets ( common practice for VDSL | cabinets ( common practice for VDSL access ). In such cases it is | |||
access ). In such cases it is the responsibility of the system | the responsibility of the system designer to take into account the | |||
designer to take into account the physical security measures ( | physical security measures ( environmental design, mechanical or | |||
environmental design, mechanical or electronic access control, | electronic access control, intrusion detection ), as well as | |||
intrusion detection ), as well as monitoring and auditing measures | monitoring and auditing measures (configuration and Operating System | |||
(configuration and Operating System changes, reloads, routes | changes, reloads, routes advertisements ). | |||
advertisements ). | ||||
Security aspects specific to the MPLS access network based on LDP DoD | Security aspects specific to the MPLS access network based on LDP DoD | |||
in the context of Seamless MPLS design are described in the security | in the context of Seamless MPLS design are described in the security | |||
section of [I-D.ietf-mpls-ldp-dod]. | section of [RFC7032]. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
9.2. Informative References | 9.2. Informative References | |||
[ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node | [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node | |||
failure, MPLS World Congress 2009", . | failure, MPLS World Congress 2009", . | |||
[ACM01] , , , and , "Archieving sub-second IGP convergence in | [ACM01] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure, | |||
large IP networks, ACM SIGCOMM Computer Communication | "Archiving sub-second IGP convergence in large IP | |||
Review, v.35 n.3", July 2005. | networks, ACM SIGCOMM Computer Communication Review, v.35 | |||
n.3", July 2005. | ||||
[BGP-PIC] "BGP PIC, Technical Report", November 2007. | ||||
[I-D.bashandy-bgp-edge-node-frr] | [I-D.bashandy-bgp-edge-node-frr] | |||
Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP | Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP | |||
FRR Protection against Edge Node Failure", draft-bashandy- | FRR Protection against Edge Node Failure", draft-bashandy- | |||
bgp-edge-node-frr-03 (work in progress), July 2012. | bgp-edge-node-frr-03 (work in progress), July 2012. | |||
[I-D.bashandy-bgp-frr-mirror-table] | [I-D.bashandy-bgp-frr-mirror-table] | |||
Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR | Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR | |||
Protection against Edge Node Failure Using Table Mirroring | Protection against Edge Node Failure Using Table Mirroring | |||
with Context Labels", draft-bashandy-bgp-frr-mirror- | with Context Labels", draft-bashandy-bgp-frr-mirror- | |||
skipping to change at page 38, line 15 | skipping to change at page 40, line 5 | |||
[I-D.bashandy-isis-bgp-edge-node-frr] | [I-D.bashandy-isis-bgp-edge-node-frr] | |||
Bashandy, A., "IS-IS Extension for BGP FRR Protection | Bashandy, A., "IS-IS Extension for BGP FRR Protection | |||
against Edge Node Failure", draft-bashandy-isis-bgp-edge- | against Edge Node Failure", draft-bashandy-isis-bgp-edge- | |||
node-frr-01 (work in progress), September 2012. | node-frr-01 (work in progress), September 2012. | |||
[I-D.bashandy-mpls-ldp-bgp-frr] | [I-D.bashandy-mpls-ldp-bgp-frr] | |||
Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node | Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node | |||
Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- | Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- | |||
bgp-frr-00 (work in progress), March 2012. | bgp-frr-00 (work in progress), March 2012. | |||
[I-D.ietf-karp-routing-tcp-analysis] | ||||
. | ||||
[I-D.ietf-mpls-ldp-dod] | ||||
Beckhaus, T., Decraene, B., Tiruveedhula, K., | ||||
Konstantynowicz, M., and L. Martini, "LDP Downstream-on- | ||||
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work | ||||
in progress), July 2013. | ||||
[I-D.ietf-rtgwg-bgp-pic] | ||||
. | ||||
[I-D.ietf-rtgwg-remote-lfa] | [I-D.ietf-rtgwg-remote-lfa] | |||
. | Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. | |||
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 | ||||
(work in progress), May 2014. | ||||
[I-D.minto-2547-egress-node-fast-protection] | [I-D.minto-2547-egress-node-fast-protection] | |||
Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress | Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress | |||
PE Fast Failure Protection", draft-minto-2547-egress-node- | PE Fast Failure Protection", draft-minto-2547-egress-node- | |||
fast-protection-02 (work in progress), July 2013. | fast-protection-02 (work in progress), July 2013. | |||
[I-D.rtgwg-bgp-pic] | ||||
Bashandy, A., Filsfils, C., and P. Mohapatra, "Abstract", | ||||
draft-rtgwg-bgp-pic-02 (work in progress), October 2013. | ||||
[PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in | [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in | |||
MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS | MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS | |||
2006 Conference", . | 2006 Conference", . | |||
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | |||
BGP-4", RFC 3107, May 2001. | BGP-4", RFC 3107, May 2001. | |||
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | |||
Networks (VPNs)", RFC 4364, February 2006. | Networks (VPNs)", RFC 4364, February 2006. | |||
skipping to change at page 39, line 12 | skipping to change at page 40, line 43 | |||
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, | for Inter-Area Label Switched Paths (LSPs)", RFC 5283, | |||
July 2008. | July 2008. | |||
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | |||
Reroute: Loop-Free Alternates", RFC 5286, September 2008. | Reroute: Loop-Free Alternates", RFC 5286, September 2008. | |||
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June | (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June | |||
2010. | 2010. | |||
[RFC5920] . | [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS | |||
Networks", RFC 5920, July 2010. | ||||
[RFC6571] . | [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., | |||
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free | ||||
Alternate (LFA) Applicability in Service Provider (SP) | ||||
Networks", RFC 6571, June 2012. | ||||
[RFC7032] . | [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | |||
BGP, LDP, PCEP, and MSDP Issues According to the Keying | ||||
and Authentication for Routing Protocols (KARP) Design | ||||
Guide", RFC 6952, May 2013. | ||||
[RFC7032] Beckhaus, T., Decraene, B., Tiruveedhula, K., | ||||
Konstantynowicz, M., and L. Martini, "LDP Downstream-on- | ||||
Demand in Seamless MPLS", RFC 7032, October 2013. | ||||
Authors' Addresses | Authors' Addresses | |||
Nicolai Leymann (editor) | Nicolai Leymann (editor) | |||
Deutsche Telekom AG | Deutsche Telekom AG | |||
Winterfeldtstrasse 21 | Winterfeldtstrasse 21 | |||
Berlin 10781 | Berlin 10781 | |||
DE | DE | |||
Phone: +49 30 8353-92761 | Phone: +49 30 8353-92761 | |||
End of changes. 67 change blocks. | ||||
153 lines changed or deleted | 239 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/ |