Subject: RE: [Isis-wg] doubts

From: Les Ginsberg <[email-masked]>
Date: Thu, 26 Sep 2002 16:22:25 -0700

(My apologies for the earlier inadvertent send of my reply before it was 
completed. Here is the complete reply).

    Les

At 05:07 PM 9/26/02 -0400, Jeff Parker wrote:
>Rams -
>         I'm not sure I'm following all of this.
>Let me draw the network, and change a few names
>to match 10589's language here...
>B is connect to D via a p2p link, and to A, E and F
>via a Bcast link
>
>                   D
>                 |
>         A*        B    E    F
>       +         +    +    +
>     ===========================
>
>A* == A is the DIS
>
>I think this is your network.
>B has recieved LSP X from D, and has set the
>SRM bit on circuit C (the circuit to the LAN).
>Section 7.3.15.2.b.1 talks about getting a
>CSPN on circuit C from DIS A
>
>         1) If the reported value equals the database
>         value and C is a non-broadcast circuit, clear
>         the SRM flag for C in that LSP
>
>Your observation is that we could safely clear the
>SRM bit on a broadcast link as well as a p2p.  If there
>are other IS's E and F on the LAN, they will have just
>seen the CSPN, so they will ask for the LSP if
>they don't have it.  Nothing is gained by sending.

Actually something is gained by maintaining the SRMflag This is one of 
those cases where the handling of a received SNP entry is not and should 
not be equivalent to handling the receipt of the matching LSP. In the 
example Jeff has provided, when the non-DIS node B receives an SNP entry 
from the DIS(A) it knows that A and B have the matching entry, but knows 
nothing about the state of this LSP in other non-DIS neighbors. In this 
example, all ISs who have recently received a new copy of the LSP in 
question will have set SRMflag on the broadcast circuit. Because LSPs are 
multicast, the first IS (DIS or non-DIS) who sends the new copy of the LSP 
will cause all other IS's on the LAN to clear the SRMflag when processing 
the received LSP (see 7.3.15.1e-iii). This will minimize the number of ISs 
who send the same copy of the LSP and will also minimize the number of 
PSNPs sent containing the corresponding SNP entry because the receipt of 
the LSP will also cause SSNflag to be cleared (see 7.3.15.1e-v).

If every IS who had the SRMflag set cleared the SRMflag on receipt of a 
CSNP with an equal entry convergence time would be lengthened because we 
would have to wait for the PSNPs to be sent by all systems which still have 
an older version even though some systems already were intending to 
propagate the new version of the LSP.

>I don't know if this has been observed before or fixed
>in some version of the draft - a brief look at the
>recent revision shows no change.
>
>As you note, there is no harm in the extra send, but
>it does seem odd that this is singled out.  There
>must be a reason
>
>Mike?  What are we missing?
>
>- jeff parker

---

From: mike shand <[email-masked]>
Date: Fri, 27 Sep 2002 09:53:25 +0100

Yes, Les has it.

To put it another way, when you receive a newer copy of an LSP you need to 
assert the presence of that LSP onto the LAN by setting SRMflags (and 
subsequently transmitting it). If you see a copy of that LSP on the LAN 
before you get around to transmitting it yourself, your desire to assert 
that LSP has been satisfied, and you are therefore justified in clearing 
your SRMflags (i.e. somebody else did what you were going to do ).

However, if you see that same LSP in a CSNP, all that tells you is that the 
DR has a copy. It tells you nothing about whether or not the LSP in 
question has been asserted onto the LAN, and hence whether or not anyone 
else MIGHT have a copy (note that sending an LSP on the LAN tells you 
NOTHING about whether anyone successfully received it). So this is NOT 
sufficient evidence for you to cancel your desire to assert the presence of 
the LSP on the LAN.

As Les correctly says, if you DID clear your flag, everything would still 
be sorted out, because those routers which didn't have a copy of the LSP 
would request one via a PSNP, and the DR would then send it.

But to be absolutely honest, I rather suspect this is all 
post-rationalization. I think the REAL reason for the "only clear SRM flags 
on a non-broadcast circuit" is simply that on a LAN SRMflags are self clearing!

Radia can correct me if I am wrong, but I don't THINK it was ever a 
conscious decision to optimize this case. Indeed I would be surprised if it 
were, because the whole design philosophy of the update process is that 
there are a very simple set of rules which will always guarantee correct 
operation under any circumstance whatever. They may not always be 
completely optimal, but they will NEVER do the wrong thing. In general the 
update process strenuously avoids rare case optimizations, on the grounds 
that special case code which is rarely exercised will almost certainly have 
undiscovered bugs in it, and optimizing rare cases is a waste of time 
anyway. The update process is not designed to be optimal. It IS designed to 
be correct.

KISS.

	Mike

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg