69th IETF Chicago July 2007 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 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 PE P(2) P(1)

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