Subject: RE: [Isis-wg] Making the update reliable

From: mike shand <[email-masked]>
Date: Thu, 24 Jan 2002 08:26:39 +0000

At 02:12 24/01/2002 -0500, Ramalingam, Swaminathan wrote:

Keon,

Whenever an adjacency comes up
(may be because of start/restart) , CSNPs are sent on p2p links.You can't
send control packets without adjacency.

Yes.

"Making the update
reliable" means how the flooding made reliable using  periodic
CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on
p2p network when it start/restarts.

The heading is something of a misnomer here. The CSNP has NOTHING to do
with reliability in the case of a p2p circuit. (It does of course on a
broadcast circuit). On a P2P, the CSNP is simply an optimization which
avoid the need to flood the entire LSP database when the adjacency comes
up between two routers which already have (most of) the database.
Reliability is of course achieved by setting SRMflags on all LSPs when
the circuit comes up and using PSNPs to ACK.

Mike

- Swami

-----Original Message-----

From: Koen Vermeulen
[mailto:[email-masked]]

Sent: Wednesday, January 23, 2002 11:55 PM

To: Isis-wg

Subject: [Isis-wg] Making the update reliable

Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the

update reliable'. At the end of this section is written for

point-to-point circuits:

When a point-to-point circuit (including non-DA DED circuits

and virtual links) starts (or restarts), the IS shall

a) set SRMflag for that circuit on all LSPs, and

b) send a Complete set of Complete Sequence Numbers PDUs

on that circuit.

My question is now: what is actually meant with this

'start' (or 'restart') of a circuit? Do they mean an

adjacency state change to 'up', or is it really the circuit

which physically gets ready to send l2-frames?

If the second answer is what is meant, then I don't

understand why a CSNP is sent. This PDU will

be thrown away anyhow by the receiving side if there is

no adjacency (see 7.3.15.2 7:

If the SNP is received on a non-broadcast circuit and

there is no adjacency of the same level (e.g. a level 1 SNP

with a level 1 or level 1 & 2 adjacency) on the circuit

over which the SNP was received, then the IS shall

discard the SNP without generating a event.

).

So how can this mechanism make the update reliable? Or am I

missing something?

Regards,

Koen

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

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 24 Jan 2002 10:11:35 -0500

Mike Shand Wrote:

The heading is something of a misnomer here. The CSNP has NOTHING to do with
reliability in  the case of a p2p circuit. (It does of course on a broadcast
circuit). On a P2P, the CSNP is simply an optimization which avoid the need
to flood the entire LSP database when the adjacency comes up between two
routers which already have (most of) the database. Reliability is of course
achieved by setting SRMflags on all LSPs when the circuit comes up and using
PSNPs to ACK.

Hi Mike,

    Doesn't a PSNP actually serve dual roles in this capacity, as a request
and as an acknowledgement?

    After a circuit restarts and we form an adjacency, ISH and IIH PDUs are
exchanged (not all implementations send ISH PDUs). Next, some
implementations transmit newly generated LSP(s) as a result of the newly
formed adjacency. By sending this LSP prior to issuing a CSNP, this
eliminates the need for the remote IS to issue a PSNP as a request for this
LSP and then issue a PSNP again as an acknowledgement for this LSP. Next,
both sides of the link set the SRMflag for all LSPs in the appropriate LSP
Ln Database, based on the adjacencyUsage (send these LSPs upon expiration of
minimumLSPTransmissionInterval). They then transmit a CSNP with entries for
all LSPs contained within the appropriate Ln LSPDB, regardless of the
SSNflag settings.

    The receiving IS processes the newly received CSNP(s) and sets the
SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP LSP
Entry reference which is non-existent in the local LSPDB, it will create an
entry in its LSPDB with a LSP Seq # = zero. It next sets the SSNflag for
this entry (request this LSP from the remote adjacency). Once the
partialSNPInterval timer expires, the PSNP shall be transmitted to the
remote IS (clear SSNflag for this LSP entry upon successful transmission of
the LSP in question). Upon receipt of this PSNP, the remote IS will think
that the adjacent IS possesses an LSP which is older than the same LSPID it
possesses in its local LSPDB (this is why the LSP Seq # is set to zero).
Consequently, the SRMflag for this LSPID entry within the local LSPDB never
gets cleared. Upon expiration of minimumLSPTransmissionInterval, this LSP is
transmitted to the adjacent IS. Upon receipt of this LSP, the receiving IS
sets the SSNflag so as to acknowledge receipt of this LSP. The LSPDBs should
now be synchronized, of course, that is if all other LSP Entries are also
processed properly.

    So, if one or both of the CSNPs were to get dropped, the LSPDBs should
still get synchronized when minimumLSPTransmissionInterval expires. This is
because the SRMflags are set when ever a CSNP is generated on a PtP link.

    Mike, does this make sense or am I just out in the weeds again?

Cheers,
Ken Larmer
CommSense Networks

---

From: mike shand <[email-masked]>
Date: Thu, 24 Jan 2002 15:18:51 +0000

At 10:11 24/01/2002 -0500, Ken Larmer wrote:
>Reliability is of course achieved by setting SRMflags on all LSPs when the 
>circuit comes up and using PSNPs to ACK.
>
>Hi Mike,
>
>     Doesn't a PSNP actually serve dual roles in this capacity, as a 
> request and as an acknowledgement?

Well, yes, but I didn't want to get into a complete description of the 
operation of the update process. I was just pointing out the fact that the 
CSNP was completely unnecessary for effective synchronization. Its function 
is ONLY to attempt to limit the amount of LSP traffic exchanged.

>
>     After a circuit restarts and we form an adjacency, ISH and IIH PDUs 
> are exchanged (not all implementations send ISH PDUs). Next, some 
> eliminates the need for the remote IS to issue a PSNP as a request for 
> this LSP and then issue a PSNP again as an acknowledgement for this LSP. 
> Next, both sides of the link set the SRMflag for all LSPs in the 
> appropriate LSP Ln Database, based on the adjacencyUsage (send these LSPs 
> upon expiration of minimumLSPTransmissionInterval). They then transmit a 
> CSNP with entries for all LSPs contained within the appropriate Ln LSPDB, 
> regardless of the SSNflag settings.
>
> SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP 
> LSP Entry reference which is non-existent in the local LSPDB, it will 
> create an entry in its LSPDB with a LSP Seq # = zero. It next sets the 
> SSNflag for this entry (request this LSP from the remote adjacency). Once 
> the partialSNPInterval timer expires, the PSNP shall be transmitted to 
> the remote IS (clear SSNflag for this LSP entry upon successful 
> transmission of the LSP in question). Upon receipt of this PSNP, the 
> remote IS will think that the adjacent IS possesses an LSP which is older 
> than the same LSPID it possesses in its local LSPDB (this is why the LSP 
> Seq # is set to zero). Consequently, the SRMflag for this LSPID entry 
> within the local LSPDB never gets cleared.

Never is a bit strong!

>Upon expiration of minimumLSPTransmissionInterval, this LSP is transmitted 
>to the adjacent IS.

possibly for the second time

>  Upon receipt of this LSP, the receiving IS sets the SSNflag so as to 
> acknowledge receipt of this LSP. The LSPDBs should now be synchronized, 
> of course, that is if all other LSP Entries are also processed properly.
>
>     So, if one or both of the CSNPs were to get dropped, the LSPDBs 
> should still get synchronized when minimumLSPTransmissionInterval 
> expires. This is because the SRMflags are set when ever a CSNP is 
> generated on a PtP link.

Well, yes sort of. they are set whenever the adjacency goes up.

>     Mike, does this make sense or am I just out in the weeds again?

It sounds a lot more complicated than what I said :-) I just didn't want to 
get dragged down this hole. The whole point about the update process is 
that it works correctly by magic. That's all you need to know :-) :-)

         Mike

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Jan 2002 08:54:37 -0800 (PST)

It does server as a reliability mechanism when pruned flooding topologies
are used (so as to make sure that the flooding topology is not partitioned)
but it is only a last-ditch mechanism in this case.

   From: "Ken Larmer" <[email-masked]>
   Cc: "Ken Larmer" <[email-masked]>,
      "Isis-wg" <[email-masked]>,
      "'Koen Vermeulen'" <[email-masked]>
   Content-Type: multipart/alternative;
	   boundary="----=_NextPart_000_000C_01C1A4BF.8162D010"
   X-Priority: 3 (Normal)
   X-MSMail-Priority: Normal
   X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
   Importance: Normal
   Sender: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Thu, 24 Jan 2002 10:11:35 -0500

   This is a multi-part message in MIME format.

   ------=_NextPart_000_000C_01C1A4BF.8162D010
   Content-Type: text/plain;
	   charset="us-ascii"
   Content-Transfer-Encoding: 7bit

   Mike Shand Wrote:

   Hi Mike,

   Cheers,
   Ken Larmer
   CommSense Networks

   ------=_NextPart_000_000C_01C1A4BF.8162D010
   Content-Type: text/html;
	   charset="us-ascii"
   Content-Transfer-Encoding: quoted-printable

   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
   <HTML><HEAD>
   <META http-equiv=3DContent-Type content=3D"text/html; =
   charset=3Dus-ascii">
   <META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
   <BODY>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial size=3D2>Mike =
   Shand=20
   Wrote:</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002>&nbsp;</SPAN></DIV>
   <DIV>The heading is something of a misnomer here. The CSNP has NOTHING =
   to do=20
   with reliability in&nbsp;<SPAN class=3D484532614-24012002><FONT =
   face=3DArial=20
   size=3D2>&nbsp;</FONT></SPAN>the case of a p2p circuit. (It does of =
   course on a=20
   broadcast circuit). On a P2P, the CSNP is simply an optimization which =
   avoid the=20
   need to flood the entire LSP database when the adjacency comes up =
   between two=20
   routers which already have (most of) the database. Reliability is of =
   course=20
   achieved by setting SRMflags on all LSPs when the circuit comes up and =
   using=20
   PSNPs to ACK.<BR><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2>&nbsp;</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial size=3D2>Hi=20
   Mike,</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002>&nbsp;&nbsp;&nbsp;&nbsp;<FONT =
   face=3DArial=20
   size=3D2>Doesn't a PSNP actually serve&nbsp;dual roles in this capacity, =
   as a=20
   request and as an acknowledgement? </FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2></FONT></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial =
   size=3D2>&nbsp;&nbsp;&nbsp;=20
   After a circuit restarts and we form an adjacency, ISH and IIH PDUs are=20
   exchanged (not all implementations send ISH PDUs).=20
   Next,&nbsp;some&nbsp;implementations&nbsp;transmit newly generated =
   LSP(s) as a=20
   result of the newly formed adjacency.&nbsp;By sending this LSP prior to =
   issuing=20
   a CSNP, this eliminates the need for the remote IS to issue a =
   PSNP&nbsp;as=20
   a&nbsp;request for this LSP and then issue a PSNP again as an =
   acknowledgement=20
   for this LSP. Next, both sides of the link set the SRMflag for all LSPs =
   in the=20
   appropriate LSP Ln Database, based on the adjacencyUsage&nbsp;(send =
   these LSPs=20
   upon expiration of minimumLSPTransmissionInterval). They then transmit a =
   CSNP=20
   with entries for all LSPs contained within the appropriate Ln LSPDB, =
   regardless=20
   of the SSNflag settings.</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2></FONT></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002>&nbsp;&nbsp;&nbsp; <FONT =
   face=3DArial=20
   size=3D2>The receiving IS processes the newly received CSNP(s) and sets =
   the=20
   SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP =
   LSP Entry=20
   reference which is non-existent in the local LSPDB, it will create an =
   entry in=20
   its LSPDB with a LSP Seq # =3D zero. It next sets the SSNflag for this =
   entry=20
   (request this LSP from the remote adjacency). Once the =
   partialSNPInterval timer=20
   expires, the PSNP shall be transmitted to the remote IS (clear SSNflag =
   for this=20
   LSP entry upon successful transmission of the LSP in question). Upon =
   receipt of=20
   this PSNP, the remote IS will think that the adjacent IS possesses an =
   LSP which=20
   is older than the same LSPID it possesses in its local LSPDB (this is =
   why the=20
   LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID =
   entry within=20
   the local LSPDB never gets cleared. Upon expiration of=20
   minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent =
   IS. Upon=20
   receipt of this LSP, the receiving IS sets the SSNflag&nbsp;so as to =
   acknowledge=20
   receipt of this LSP. The LSPDBs should now be synchronized, of course, =
   that is=20
   if all other LSP Entries are also processed =
   properly.</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002>&nbsp;&nbsp;&nbsp;&nbsp;<FONT =
   face=3DArial=20
   size=3D2>So, if one or both of the CSNPs were to get dropped, the LSPDBs =
   should=20
   still get synchronized when minimumLSPTransmissionInterval expires. This =
   is=20
   because the SRMflags are&nbsp;set when ever a CSNP is generated&nbsp;on =
   a PtP=20
   link.</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002>&nbsp;&nbsp;&nbsp;&nbsp;<FONT =
   face=3DArial=20
   size=3D2>Mike, does this make sense or&nbsp;am I just out in =
   the&nbsp;weeds=20
   again?</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2></FONT></SPAN>&nbsp;</DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2>Cheers,</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2>Ken&nbsp;Larmer</FONT></SPAN></DIV>
   <DIV><SPAN class=3D484532614-24012002><FONT face=3DArial=20
   size=3D2>CommSense&nbsp;Networks</FONT>&nbsp;</SPAN></DIV></BODY></HTML>

   ------=_NextPart_000_000C_01C1A4BF.8162D010--