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

List:       ms-ospf
Subject:    Re: determining the new LSA
From:       zhou wenhui <zwh () MAIL ! NDSC ! COM ! CN>
Date:       1999-12-02 1:51:03
[Download RAW message or body]


Radia:
I know what's your meaning. In your opinion,in fact,
the "simple meathod" is complex because it needs to
match the long string.
First,I just think that when two LSAs have the same LS SeqNum,
LS checksum and LS age field, maybe these two LSAs are
not identical completely,so the probability that router A chooses
one and router B chooses other one exists. Second,when two LSAs
have the same LS SeqNum and LS checksum,we need to turn to
the age field, at this situation, the "simple meathod" is simple.
Now, I know I have made a big mistake: the probability for two
LSAs have the same LS SeqNum and LS checksum is small.In fact,
it is close to impossible.

When we choose the LSA which has greater age value,
The probability we choose the wrong one is 50 percent,right?
I think so.






>        From: zhou wenhui <zwh@MAIL.NDSC.COM.CN>
>
>        But I think these are simple methods to guarantee all
>        routers choose the same LSA when things occur.
>        For example,match the two LSA bit by bit(except for the
>        age field),when the first bit is different(1 or 0),choose
>        the larger one.
>
>        When we choose the LSA which has greater checksum value,
>        The probability we choose the wrong one is 50 percent,right?
>
>You're right. The probability of TEMPORARILY choosing the wrong
>one is 50%. But it's not a problem since it quickly converges
>properly once the wrong one gets back to the originating router, since
>that will then issue a new "right" one with a higher sequence number.
>
>And your "simple method" is actually the example of using the
>data itself as a checksum, which is an interesting
>concept.
>
>The advantages of using a fixed-size checksum rather
>than using the data itself as a checksum are:
>   a) you can detect all by yourself if an LSA has somehow gotten
>      corrupted while sitting in memory (otherwise you'd have to
>      check by comparing the data with your neighbors)
>   b) the checksum is a shorthand quick way of comparing with
>      a neighbor and has a high probability of detecting different data.
>      This saves bandwidth in acknowledgements (since the sequence
>      number and checksum are all you have to send...not the whole
>      data), and CPU (since you only have to compare a small
>      checksum rather than the complete data).
>
>
>Radia
>

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