Why Is OSPF (Or IS-IS) Afraid of Unequal-Cost Load Balancing

You might have wondered why no link-state routing protocols support unequal-cost load balancing (UCLB). Petr Lapukhov provides part of the answer in his Understanding Unequal-Cost Load-Balancing article: EIGRP is one of those few protocols that can ensure a neighbor is not using the current router as its next-hop.

However, one has to wonder: with OSPF and IS-IS having the entire network topology (or at least the intra-area part of it) in the SPF tree, how hard would it be to detect that sending a packet to a device that is not on the shortest path results in a forwarding loop? Is the lack of OSPF or IS-IS UCLB in Cisco IOS the result of lip service to the standards (at least the OSPF one is way too prescriptive) or a shoddy implementation? What are your thoughts?

Recent posts in the same categories

8 comments:

  1. Anonymous 03 May 2009 03:30
    "You might have wondered why no link-state routing protocols support unequal-cost load balancing"... Isnt that precisely what TE metrics let you do with an MPLS backbone?
  2. Ivan Pepelnjak 03 May 2009 10:29
    You're absolutely correct (see my Perfect load balancing article for details) ... but why is the UCLB functionality not available in pure OSPF/IS-IS?
  3. Ofer 03 May 2009 15:04
    In my opinion -

    I believe UCLB is possible, but it will require major changes to the SPF algorithm, mainly becuase SPF doesn't know what lies ahead - it grows from the the root to the leaves. so calculating an alternative path, for EVERY node and checking the FC for it (the implication would be not to remove the root neighbor node's triplet from the TENT list until it is checked agianst every node that enters the PATH list, for the FC), when just in the building process seems quite intense.

    Link state protocols get raw data and calculate the SPF tree. Distance vector protocols get processed data - they don't have to run any calculations, just pick the lowest.

    So i am guessing implementing UCLB in distance vector protocols (or OSPF inter-area), by adding communication of advertised distances between neighbors, will be less difficult to implement than in OSPF/IS-IS intra-area.
  4. Jen Rexford 03 May 2009 16:19
    There has been some work on link-state protocols with splitting over non-shortest paths, by putting exponentially diminishing fractions of the traffic on longest paths. This actually works quite well and can, in fact, enable "optimal" traffic engineering simply by tuning the links weights. See, for instance, the work in:


    http://www.research.att.com/~dahaixu/pub/nem/pefti.pdf
    http://www.research.att.com/~dahaixu/pub/deft/deft.pdf

    for details.
  5. Anonymous 04 May 2009 09:29
    Wow, there are prestigious readers on this blog ;-)
  6. Petr Lapukhov 04 May 2009 11:56
    To Ivan: well, as I mentioned previously, RFC5286 defines to appication of LFA concent (Loop-Free Alternative) in the context of link-state routing protocols such as OSPF and ISIS. This leads us to the brave new world of IP FRR :)

    To Jen: thanks for providing some really interesting reading! I feel like i'm going to get stuck in those for the few next days :)
  7. Anonymous 07 May 2009 20:22
    That will prone to cause routing loops in my opinion. Especially when a path / router goes down and SPF needs to recalculate again on an UCLB Network...
  8. jsicuran 22 September 2010 21:11
    Actually, the UCLB question could be answered in terms of histroy and features. The designers of OSPF and IS-IS at their time of origination never envisioned the type of networks we would have today and even during their protocol evolution over time to factor that "feature" in. The other consideration is that the mold was made for these protocols and integration of UCLB would be too difficult and costly for the many distros of the protocols.
    Now UCLB can be "added" on top of the routing protocol just like another policy routing type feature or feature in general. Look at BFD and Ethernet CFM that could have been designed in the beginning but it was not and thus now it is available as an option to enhance the underlying protocols operation.

    So, maybe in IOS 16 we will get a UCLB knob for OSPF and IS-IS.
Add comment
Home
Sidebar