1. An analysis of scaling issues in MPLS-TE backbone networks
Seisho Yasukawa, Adrian Farrel, and Olufemi Komolafe
draft-yasukawa-mpls-scaling-analysis-04.txt
69th IETF Chicago July 2007

2. Introduction
Motivated by concerns about potentially excessive number of LSPs in MPLS-TE networks
PE-PE LSPs required in a full mesh
Multiple ‘parallel’ LSPs for service differentiation
How many LSPs can a core P-node support?
The old n-squared problem re-surfaces
Simple math… 1000 PEs means up to LSPs in the core (per service type)
Important issue because number of LSPs supported by LSR constrained by factors such as
Amount of LSP state
Processing overhead
RSVP-TE overhead
Management complexity
Open questions include
Does use of hierarchical LSPs solve problem?
Are there other solutions?
69th IETF Chicago July 2007

3. Progress Last discussed in Dallas (March 2006) Updates
Added discussion of “ladder topology”
New author: Femi from Glasgow University
Checked (and corrected) the math
Revised to clarify the problem and objectives
69th IETF Chicago July 2007

4. Approach
Use exemplar topologies to give insight into potential MPLS-TE scaling issues
Exemplar topologies
Have characteristics similar to real networks
e.g. tree-like at edges, mesh-like in core
Have well-defined connectivity and symmetry
Amenable to mathematical analysis
Exemplar topologies considered in draft
Snowflake topology
Ladder network topology
69th IETF Chicago July 2007

5. Exemplar Snowflake Network
Meshed core of P(1) nodes
P(n+1) nodes connected to P(n) nodes
PE nodes connected to P nodes
Well-defined connectivity and symmetry allows many important metrics to be computed
Number of levels & number of nodes per level may be varied PE
P(2)
P(1)
69th IETF Chicago July 2007

6. Exemplar Ladder Network
Core of P(1) nodes looks like a ladder
Symmetrical trees subtended to core
P(n+1) nodes connected to P(n) nodes
PE nodes connected to P nodes
Well-defined connectivity and symmetry allows many important metrics to be computed
Number of levels & number of nodes per level may be varied
P(1)
P(2) PE
69th IETF Chicago July 2007

7. Method
Using Snowflake & Ladder network, can study MPLS-TE scaling, considering
Flat networks
Forwarding adjacencies (hierarchical LSPs)
MP2P LSPs
Interesting metrics include
Number of PEs
Number of LSPs traversing different LSRs
Amount of LSP state at any LSR
Ratio of PE to P LSRs (cost-effectiveness)
69th IETF Chicago July 2007

8. What are the Scaling Limitations?
Number of labels on a link
Signaling state on an LSR
Simple constraint on memory usage
Signaling processing
Searching control blocks
RSVP-TE soft state (even with refresh reduction)
RSVP-TE Hellos
Management
How many LSPs can the EMS/NMS handle
Monitoring
What management protocol load can the network support?
Status and statistics
69th IETF Chicago July 2007

9. Normal Suggestion - Hierarchy
Hierarchical LSPs scale well, but:
Not as well as you might think
Obviously no benefit from core tunnels
PE-PE tunnels don’t help n-squared problem
Multiple layers of hierarchy needed to make full impact
Tunnel end-points see increase in state
Adds a significant management overhead
All tunnel end-points have to be planned
All tunnels have to be provisioned
Auto-mesh can help
Other issues:
OAM for PE-PE LSPs is degraded
Loss of information inside the tunnel
LSP aggregation reduces PE-PE TE possibilities
TE bandwidth granularity is reduced
69th IETF Chicago July 2007

10. A Scaling Alternative – MP2P LSPs
LSPs “merge” automatically
Reduces number of LSPs towards the egress
Bandwidth has to be increased on downstream legs
69th IETF Chicago July 2007

11. Savings and Issues with MP2P
MP2P LSPs give:
Good scaling of LSP numbers near egress
No benefit near ingress
Particularly good on ladder topologies
LSP numbers is not everything!
LSP state scales slightly less well
Traffic disambiguation may be needed
Same issue as LDP – what is the source?
New functional controls needed
Control of merging lies with the ingress or the egress?
Management of explicit routes
Resource sharing or resource increments?
New protocol extensions needed
To control the function above
For OAM
69th IETF Chicago July 2007

12. Next Steps Close off this I-D with a little more polish
Progress to RFC as individual submission
Will (presumably) attract MPLS WG review in last call
Persuade community that the problem is real
Encourage implementers to develop solutions
MP2P first proposal in draft-yasukawa-mpls-mp2p-rsvpte-02.txt
Happy to see any solution
69th IETF Chicago July 2007