Curtis Villamizar and Mr Katz,
First, let me state as I did earlier, I do feel more resources
dealing with handling of Updates pkts containing refresh age
LSAs WOULD yield a higher benefit. And since we are not able
to speed up a REMOTE router's execution of of various tasks, we
need to concentrate on our on local tasks to allow US to LOCALLY
converge ASAP.
But, we are in this forwarding table vs OSPF routing table
costs, benefit analysis..
Lets see if we agree on these things.
1) Most LSAs recieved are just age refresh LSAs, thus they
have no effect on SPF calcs.
2) Most SPF calcs do not result in a lower cost route or
in some implementations a additional equal cost route.
3) Even if a OSPF routing table will yield a better cost
route than earlier in time, due to administrative
distances that newer cost, may not still be used.
Then the forwarding table mods are rarely even done!
So, why would you want to spend time to decrease the
latency of a operation on such a infrequent event?????
If subsec hellos or equivalent operation was used, I would
first verify that nbr lookups are efficent..
The freq/repeativeness of a operation, if speeded up, should
yield the best results..
So, if we aggregate the number of repeativeness operations, we
need to do 1 lookup per recived LSA within our routing table.
Most of these will result in age refreshes. So, first, the
LSA lookup is stressed the most.
Then if we had a extremely fast SPF type calcs based on different
LSA types / triggers, we COULD re-run repetive calcs withoout forcing
a delay. A delay is standand in our industry. However, if we agree
with #2 and #3, then the only reason for the delay is due to slower
SPF calcs. I agree some minimal delay is necessary to verify that
all new LSAs within a single Update, given that a full ajacency has
already been established, should be implemented.
Lastly, bringing back up the forwarding table. The table COULD be
considered somewhat like a cache. Specific atomic operations are
normally
implimented because of single change entries. A operation could
simply Invalidate an entry. This is a single small amount of data that
needs to be transfered and even slow PCI buses are capable of handling
a infrequent data with minimal latency. Most of this is done in
hardware. Sorry, it is a don't care whether their are multiple readers
for a entry if that entry needs to be invalidated or updated. We don't
wait for the readers to finish. We need to pre-empt them NOW.
Thus, given appropriate resouces, I would creare a set of equal LM
Bench
micro benchmarks, against the routing table and identify what items are
given higher priorities. I would not be surprised if these items had
not already been given quite a bit of fine tuning..
The only major issues are the best case versus worse case numbers,
and whether those best case numbers can be improved while not
increasing the worse case numbers.
Lastly, the assumption is whether BGP is in the environment? If it is,
IMO TCP would be the limiting factor. TCP will not allow a large burst
of data on a periodiclly idle connection. Most implmentations will fall
into a slow start methodology. This is the same problem with LDP even
when a path has been established with a specified bandwidth. TCP most
likely will initially get in the way and only after a sustained number
of segments transmitted will it allow the bandwidth to increase 1
segment per round-trip-time (rtt). This is known as the congestion
avoidance (CA) phase.
Mitchell Erblich
-------------------
Curtis Villamizar wrote:
>
> In message <[EMAIL PROTECTED]>
> Erblichs writes:
> >
> >
> > The biggest reason for this is because the forwarding
> > tables need faster memory. If we assume that forwarding
> > table memory is 4x faster than routing table memory,
>
> Nice try but ...
>
> The forwarding memory is on another card in a reasonably big router
> and therefore the information has to be trasferred from one processor
> to another and then installed in the forwarding memory.
>
> Also the forwarding memory is primarily used for forwarding and in a
> big busy router not too many cycles are left over for the writes that
> update the forwarding memory due to the reads that are occurring
> concurrently. In some architectures this is minimized. For example,
> some may use memory caching techniques others dual memory banks, etc.
>
> But perhaps the biggest factor is that the few hundred or few thousand
> IGP routes are the basis for BGP next hops so after they are computed
> the few 100,000 BGP routes and forwarding entries are mapped onto the
> SPF results. Since there are usually more than 100 times as many BGP
> routes as IGP routes doubling the speed of the SPF has no effect.
>
> In any case, Dave is right. The SPF typically takes far less time
> than the things that happen as a result of the SPF.
>
> Curtis
>
> ps - OTOH the speed of the MPLS/TE CSPF is very significant.
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
