[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: ? about external LSA load balancing
From:       "Pat Murphy - (650)329-4044" <pmurphy () NOC ! DOI ! NET>
Date:       2000-02-24 2:47:36
[Download RAW message or body]


Alex,

>recall that routers connected via a p-t-p link can both announce the
>same prefix assigned to the link.

Isn't each intra-area routing table entry generated by the SPF tree made
up of distinct next hops, even in this case? Inter-area routes and
external routes do seem to share the same pruning dilemma which may
infer an unwarranted load balance.

In my original example a case could be made for "not pruning" by
comparing the load balance of the different branch heirarchies as you
descend down from A. The intent of that example was to demonstrate
unbalanced loads. It did not make a very good case for pruning.
Since my last example is defunct, here is one which does show the
inconsistency of not pruning.

                A
               / \
              /   \
             /     \
            /       \
           B1        B2
          /  \      /  \
        C11  C12  C21  C22
          \  /      \  /
           E1        E2
           |         |
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~
     RIPv2 cloud of networks

Here E1 speaks only RIPv2. C11 and C12 both advertise the RIPv2 cloud
with a 0.0.0.0 forwarding address. E2 speaks OSPF and can generate its
own advertisements for the RIPv2 cloud. Thus router A sees three equal
cost advertisements for each network in the RIPv2 cloud, one each from
C11, C12, and E2. With pruning, the OSPF routing table infers an equal
load share between the A-B1 and A-B2 hops, as it should. Without pruning
the OSPF routing table infers that the A-B1 hop should receive twice the
load as the A-B2 hop.

Consider a second example which I have inverted so it can apply to
inter-area traffic. Here links are assigned cost based on bandwidth.

         B1        B2
        /  \      /
512kbps/    \ T1 /T1
      /      \  /
     C1       C2
      \      /
    T1 \    /512kbps
        \  /
          I

All routers are part of the same non-zero area. B1 and B2 are border
routers. Assume the summary LSAs originated by B1 and B2 have equal
costs and prefixes. Internal router I has two next hops to B1 while
there is only one next hop to B2. If OSPF doesn't prune, the I-C2 load
inference is twice that of the I-C1 load, despite the fact the I-C1 path
has three times more capacity.

In both examples, without the SPF tree A does not know what the topology
is even one hop downstream. There could be routers D1,D2,D3,D4 feeding
traffic into a transit router in one of the paths so that even if A did
look at the SPF tree, without traffic engineering, it is presumptuous of
A to unbalance the load. All A knows for sure is that it has two
distinct next hops for which it has equal cost paths. A should not
build a routing table which infers an unbalanced load without good
traffic engineering (in my opinion).

Pruning doesn't have to be part of the spec. However, I would like to
see it mentioned as a current best practice. Not only does it insure
that OPSF intra-area, inter-area, and inter-AS traffic load consistently
on each next hop, it also insures consistent loading compared to other
routing protocols operating in the same AS, while at the same time
motivating consistent interoperability between OSPF implementations.
Load balancing is best achieved by using a consistent algorithm. Pruning
allows one to view a consolidated routing table of all the routing
protocols and know that load was distributed the same way by each of
them. I hope this is not just a dream.

Pat

################################################################
# Patrick W. Murphy, Ph. D.    | TEL (650)329-4044             #
# Computer Scientist           | FAX (650)329-4026             #
# U.S. Geological Survey       | Internet: pmurphy@wr.usgs.gov #
# Menlo Park, California, USA  | NSINET - isdmnl::pmurphy      #
################################################################

[prev in list] [next in list] [prev in thread] [next in thread]