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

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

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

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

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

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

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

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

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

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

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

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