80 likes | 173 Views
“Divided we stand, united we fall” Implications of Multiple Diff-Serv Ordered Aggregates over a single E-LSP. Shai Herzog Salt-Lake City IETF 6 September 2014. Multiple OAs over single LSP. Sub-dividing parameters can be hazardous to the health of the network Multiple BW, CSPF, etc.
E N D
“Divided we stand, united we fall”Implications of Multiple Diff-Serv Ordered Aggregates over a single E-LSP Shai Herzog Salt-Lake City IETF 6 September 2014
Multiple OAs over single LSP • Sub-dividing parameters can be hazardous to the health of the network • Multiple BW, CSPF, etc. • Can unexpectedly produce decision conflicts, cascading collapse, and serious network failure and service interruption • Serious doubt that this approach even provides savings or improves scalability • Less LSPs, but… • More processing per LSP, and more complicated implementations • Increased probability for failure -> overhead of dealing with failures • Higher human resources (imposes burden to make sure there is no chance of failure) • Needs yet another extension to the standards.
Multiple Independent Parameters - per OA • Data Path vs. Control Path (signaling) parameters: • Control Path parameters (CPP): can influence the LSP setup (route, BW, etc.) • BW requirements can modify ad. control decision and path selection (CSPF) • Data Path parameters (DPP): can only influence packet service not the LSP setup • OA per se (no admission control, no reservation) can never directly affect the LSP setup, only the service experienced by packets • Most parameters in LSP TE signaling are of Control Path nature. • Multiple independent CPP can produce conflicting results at any time • Confuses LSP -> Need conflict resolution algorithm (out of many) • The choice of resolution algorithm must be either • Universal (for consistency) or signaled (for the LSP only) • Guaranteed to not drive into network collapse under any circumstances • It is hard to predict side effects of a certain algorithm in a reasonably sized real network
Example 1: Domino Effect • Pick a network with DS setting: EF=3%, AF1=7%, AF2=20%, AF3=50%, BE • Extensive use of E-LSPs with multiple OAs • Classes are relatively full (heavy network usage) • Contention resolution algorithm: LSP is install only if all OAs individually passed AC. • Lets assume the following E-LSP bundling: • EF+AF1, Priority High • AF1+AF2, Priority Mid • AF2+AF3, Priority LOW • Event: Highest priority EF conference cause EF class saturation on some links • EF+AF1 E-LSPs get preempted, look for an alternate route, and preempt AF1+AF2 • AF1+AF2 E-LSPs get preempted in a similar manner, and preempt AF2+AF3 • AF2+AF3 find no where to go, or if lucky displaces BE traffic on specific the links. • Event: conference ends… some time…another conference starts • Everything shifts back to original state, only to cycle again
Example 2: Multiple Routing Constraints • E-LSP with multiple OAs, and BW routing constraint • Conflicts: choosing a next hop for the LSP • Next Hop conflicts when each class’s available BW is on a different link • Conflict resolution algorithm: create LSP only if all classes need/have the same path • Network State • All E-LSPs include OAs with the same path (no conflicts). • Event: Conference (again) AF1 with high priority saturates AF1 on some links • AF2 path remains the same (no events there) • AF1 path changes for all E-LSPs going through these links (bypass or backup paths) • Consequence: All E-LSP fail instantly • None of them can find a single path for both AF1 & AF2 • Lots of RED lights show up on console
Implications • Bundling multiple OAs can cause unexpected cascading effect • Problem with a small class (EF,3%) becomes a global problem of multiple classes • No isolation of failure modes • Exactly the opposite from good engineering which aims to identify and isolate failure modes • It will be hard for an operator or NMS to figure out the root of the problem and fix it • They may apply fixes to the wrong classes. • “Divided we stand, United we fall”. • Combinations fail where all sub-parts would have succeeded • The constrained routing example: • Individually AF1, AF2 would have succeeded • Together both fail
Conclusions • Multiple independent “Control Path” parameters • Dangerous! • Don’t save much, if any • BAD IDEA! • Why not leave it as an option: • Optional is for complex good mechanism that not always justify their overhead • NOT for hazardous mechanisms meant for self hangin • Freedom of adventure and risk taking • IETF shouldn’t give its seal, not even as optional mechanism • “Optional”= Good but pricy mechanism, not for everyone • NOT: Bad for some, we can’t fully predict its impact • (Here’s a rope, go …)