Subject: [Isis-wg] SRMflag & SSNflag settings

From: [email-masked]
Date: Tue, 12 Sep 2000 16:44:27 -0400

Hi,
   I hope this is the correct forum for asking these questions. I am
developing an IS-IS technology course and I have some questions, which I
can't seem to get the answers to. I have included a text version of my
questions and also a word attachment. I apologize for the lengthy
questionnaire, though I appreciate any assistance in this area!

   I am trying to determine the correct settings for the SRMflag and
SSNflag when a CSNP or PSNP are received over a Point-to-Point or Broadcast
link. ISO-10589, Section 7.3.15.2, sub-section b) details what actions to
take with respect to the SRMflag and the SSNflag when a SNP (either CSNP or
PSNP) are received over a circuit (either broadcast or non-broadcast). It
states the following: My interpretations and questions are proceeded by #.

7.3.15.2 Action on Receipt of a Sequence Numbers PDU
When a Sequence Numbers PDU (Complete or Partial...) is received on
circuit C the IS shall perform the following functions:
a) Perform the following PDU acceptance tests:
...
...
...
...
b) For each LSP reported in the Sequence Number PDU:

1)If the reported value equals the database value and C is a non-broadcast
Circuit, Clear SRMflag for C for that LSP.

#Non-broadcast:
#PSNP received - Acknowledged receipt of LSP. 
#What do we do with the SSNflag?

#CSNP received - Don't update a LSP on a circuit where an adjacent IS
already possesses it.
#Again, what do we do with the SSNflag?

#Broadcast:
#PSNP received - The DR sets the SRMflag for this LSP to update the LAN IS
requesting this LSP.
#Is this interpretation correct?

#CSNP received - Do nothing, the LSP databases are synchronized with respect
to this LSP.
#Is this interpretation correct?

2)If the reported value is older than the database value, Clear SSNflag, and
Set SRMflag.

#Non-broadcast:
#PSNP received - Acknowledgement of a received LSP, however, since the LSP
was propagated minimumLSPTransmissionInterval expiration (lastSent) onto
this circuit, the receiving IS has received a newer version of this LSP.
Consequently, it will update the adjacent IS. 
#Is this why the SSNflag is cleared? 

#CSNP received - Update the adjacent IS.
Why are we clearing the SSNflag? If this is circuit initialization, because
we just received a CSNP, should any SSNflags for this circuit be set? Or,
could the circuit have restarted and the SSNflags may represent a left over
state?

#Broadcast:
#PSNP received - Does this mean that the requesting IS is out of date
(perhaps dropped the latest CSNP due to congestion and is just getting
around to requesting an update) and DR may have had its LSP updated since it
sent the last CSNP?
#If not, why are we requesting an older LSP? 

#CSNP received - Update the DR.

3)If the reported value is newer than the database value, Set SSNflag, and
if C is a non-broadcast circuit Clear SRMflag.

#Non-broadcast:
#PSNP received - We are acknowledging a newer LSP than the adjacent IS
possesses.
#Why is the adjacent IS acknowledging a LSP we have not sent them? Or could
this be a previous incarnation?

#CSNP received - Do not update the adjacent IS with an older LSP. 
#Though, why set the SSNflag? 

#Broadcast:
#PSNP received - We are requesting a newer LSP than the DR possesses. Why is
this IS requesting a newer LSP and what should the DR do in this
situation?

#CSNP received - Request an updated LSP from the DR.  

4)If no database entry exists for the LSP, and the reported Remaining
Lifetime, Checksum and Sequence Number fields of the LSP are all non-zero,
create an entry with sequence number 0 and set SSNflag for that entry and
circuit C. Under no circumstances shall SRMflag be set for such an LSP with
zero sequence number.

#Non-Broadcast:
#PSNP received - This makes no sense for a PSNP. 
#???

#CSNP received - Create an entry, but do not propagate.
#Why set the SSNflag for a LSP we have not yet received?

#Broadcast:
#PSNP received - This makes no sense for a PSNP.
#???

#CSNP received - Create an entry, but do not propagate and request this LSP
from the DR.

Regards,
Ken Larmer
CommSense Networks

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 12 Sep 2000 18:08:12 -0400 (EDT)

I don't have the time to answer thoroughly, but let me
make a comment that will hopefully make things easier to
understand.

I don't remember why this was specified as two binary
flags SRM and SSN. Instead I think it's clearer to think
of it as a single "state" variable with 3 settings:
   OK (don't need to send ack or LSP)
   ACK (i.e., SSN, need to send ack)
   XMIT (i.e., SRM, need to transmit LSP)
   
You never should have both SSN and SRM flags set. You send
an ack once and then change the state to "OK". You send an LSP if
SRM is set (state is "XMIT") until you get an ack or the same
LSP from that neighbor. If an ack, you change state to "OK". If you receive
the same LSP from a neighbor N you set the state
to "ack" for that neighbor. If you receive a new LSP from N you set
the state to N to "ack" and to everyone else as "XMIT". You keep
transmitting to a neighbor until you get an ack from that nbr, or
the same LSP from that nbr.

This isn't very complete, I'm sure...but the main thing I wanted
to clarify is (unless I've completely forgotten this...it's been
about 85 years ... ) that you'd never want both SSN and SRM set.

Radia

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg