Subject: Re: [Isis-wg] Ack'ing LSP on P2P

From: Dave Katz <[email-masked]>
Date: Fri, 1 Feb 2002 00:09:15 -0800 (PST)

I've question that is related to the LSP ack mechanism based on what
   I observed from one of the vendor's router.

	   If the router has two p2p interfaces, Int-A and Int-B,  

	   If on Int-A, a LSP (Seq # X) is rx and the router forwards the LSP
   to Int-B ( it is also expecting an Ack from the interface).

	   Then, before an Ack is received on Int-B, a newer instance of the
   same LSP (Seq # Y > X) is received from Int-A again, 

	   On Int-A, the router sends out PSNP to ack the latest received LSP
   (Seq # Y > X)

	   We observed that the router is still sending out LSP (Seq # X). (we
   purposely configure the other router that connected to Int-B to slow down on
   sending the Ack out).

	   Shouldn't the next LSP sent out from Int-B be LSP (Seq #Y > X) ?

This behavior is purely legal, so long as the higher sequenced LSP is
eventually transmitted out of of Int-B.  Without knowing more, it is
hard to say whether this is just unlucky timing, or an implementation
that would be really fun to put in a really big and unstable network
(but then I have odd ideas about fun.)

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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 01 Feb 2002 05:43:13 -0800

> (but then I have odd ideas about fun.)

Since you're going the 'how-do-we-implement-s....' path [ where s.... stands for
software of course ;-)  ]  let's have it albeit we should not let the list deteriorate
into wall-of-flames about an implementation being better than the other. And
the moment any vendors (except predominant ones which don't care ;-) get
insulted by name, we'll have to call timeout of course!

The only reason I saw such behavior recently was when there was _plenty_ of interface
and plenty of  LSPs to send around or shortly  Heavy Load (TM).
Basically what was happening was that
the LSPs were generated as bits and bytes and buffered on outgoing interface
buffers, I/O cards, wherever the I/O system had buffers. Then it's kind of
hard to jump in and say, 'oh, you kernel there, go quickly scan all your mbufs and
replace anything that was X with Y'.

But within the protocol code it's kind of trivial to keep the pointer from the
re-transmit interface queue (if one chooses that architecture, I normally don't
like it too much for scaling) and hten the pointer points to version Y next time
it gets to transmission automatically ( I assume nobody keep X and Y at the
same time in the database, that would be too brain-twisted).  Or if one
chooses to keep interfaces to be transmitted/retransmitted on in LSP, same
thing applies.   But maybe and only maybe, somebody keeps _full_ copies
of LSPs on the re-/transmit queues which is positively scary [my first OSPF attempt ever
was doing that ;-) since I was tired of chasing the 'I had a pointer on
retransmission list and for some reason the LSP went away and my pointer
dangled' problems. But then, IP was just a freebie hack, life was good and
I didn't have to scale ;-) ]

So if there is no load and things go really slowly and the described obvious naivety
is not, we may learn something from the reasoning why such a thing shall happen.

    thanks

    -- tony

---

From: Dave Katz <[email-masked]>
Date: Fri, 1 Feb 2002 10:36:04 -0800 (PST)

Pretty much what I said.  ;-)

--Dave

       thanks

       -- tony