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

From: "Suresh Boddapati" <[email-masked]>
Date: Thu, 24 Jan 2002 15:12:48

The loss of the initial CSNP on ptop links causing inconsistent databases 
per the three-way-handshake draft brings up a question. Once the adjacency 
is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are 
serving as Acks on a ptop link, why not resend CSNPs for those LSPs that 
have not been acked within a period of time, until all LSPs get acked and 
the database is synchronized? Any new LSPs received in the meantime can 
still be flooded normally. There is nothing in the state machine either that 
precludes receiving CSNPs on ptop links at any point of time.

Regards,

Suresh

>From: Jeff Learman <[email-masked]>
>To: "Ramalingam, Swaminathan" <[email-masked]>
>CC: "'Koen Vermeulen'" <[email-masked]>,   Isis-wg 
><[email-masked]>
>Subject: RE: [Isis-wg] Making the update reliable
>Date: Thu, 24 Jan 2002 08:25:55 -0500
>
>
>Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
>so the update reliability isn't there for PPP unless you also use the 3-way
>handshake.  Fortunately, loss of the initial CNSP would only cause problems
>until every router had regenerated its LSP -- within 20 minutes using 
>default
>LSP regen timer.  See the 3-way draft for other problems that can happen
>because of running IS-IS over an unreliable link.
>
>Jeff
>
>At 02:12 AM 1/24/2002, 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.
> >
> >"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.
> >
> >- 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
> >

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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

---

From: Jeff Learman <[email-masked]>
Date: Thu, 24 Jan 2002 10:58:06 -0500

First of all, I think I made a mistake as evident from Mike S's reply.
Since flags are set for all LSPs, they would all be sent and the CSNP
is simply an optimization.  The problem I referred to happens when only
one side resets on an unreliable link AND the initial CSNP is lost.

Without the 3-way handshake, if one side resets, the other side doesn't
set the flags.  If it also doesn't receive the CSNP, it won't forward
any LSPs. This problem persists until every IS regens its LSP.
While this would be remedied more quickly using a periodic CSNP on
unreliable PTP links, the 3-way fixes this problem promptly and more
efficiently.

So I don't see any benefit to sending periodic CSNPs.  It was worth
considering, though.

Regards,
Jeff

At 10:12 AM 1/24/2002, Suresh Boddapati wrote:
>The loss of the initial CSNP on ptop links causing inconsistent databases per the three-way-handshake draft brings up a question. Once the adjacency is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are serving as Acks on a ptop link, why not resend CSNPs for those LSPs that have not been acked within a period of time, until all LSPs get acked and the database is synchronized? Any new LSPs received in the meantime can still be flooded normally. There is nothing in the state machine either that precludes receiving CSNPs on ptop links at any point of time.
>
>Regards,
>
>Suresh
>
>
>>CC: "'Koen Vermeulen'" <[email-masked]>,   Isis-wg <[email-masked]>
>>until every router had regenerated its LSP -- within 20 minutes using default
>>>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.
>>>
>>periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
>>>
>>>- Swami

---

From: Naiming Shen <[email-masked]>
Date: Thu, 24 Jan 2002 22:33:57 -0800

] The loss of the initial CSNP on ptop links causing inconsistent databases 
 ] per the three-way-handshake draft brings up a question. Once the adjacency 
 ] is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are 
 ] serving as Acks on a ptop link, why not resend CSNPs for those LSPs that 
 ] have not been acked within a period of time, until all LSPs get acked and 
 ] the database is synchronized? Any new LSPs received in the meantime can 
 ] still be flooded normally. There is nothing in the state machine either that
 ] precludes receiving CSNPs on ptop links at any point of time.
 ] 

True. But it does not seem to help much if you keep sending CSNPs either.

In the case no 3way hello is running, the first CSNP is lost, and
the link becomes unidirectional, no matter how many CSNPs being
sent later on, the two sides still can not syncronize, or it does get
syncronized but one side will keep sending out LSPs due to no Ack
back from the peer.

In the case of the link being bidirectional, the initial CSNP got lost.
All LSPs will be sent over the link, and the other side has to send back
the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A.
A has to response with PSNPs. Even A keeps sending csnps to B, A still
need to send those PSNPs. And they basically contain the same info: don't
send them anymore!

It does seem to help, if before you send any LSPs, just send a couple
of CSNP sets fast, hopefully one set gets through. Or PSNP also be able to
Ack the CSNPs received, so both sides are sure CSNPs get through fine.
But it does seem over optimization. And it only matters when two
isolated portion of the network being first brought up through this p2p
link. It does not sound like in a fast reroute of the VoIP traffic case;-)
So just let it take some time, allow all the LSPs take their own pace
through the poor p2p link...

 ] Regards,
 ] 
 ] Suresh
 ] 
 ] 
 ] >From: Jeff Learman <[email-masked]>
 ] >To: "Ramalingam, Swaminathan" <[email-masked]>
 ] >CC: "'Koen Vermeulen'" <[email-masked]>,   Isis-wg 
 ] ><[email-masked]>
 ] >Subject: RE: [Isis-wg] Making the update reliable
 ] >Date: Thu, 24 Jan 2002 08:25:55 -0500
 ] >
 ] >
 ] >Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
 ] >so the update reliability isn't there for PPP unless you also use the 3-way
 ] >handshake.  Fortunately, loss of the initial CNSP would only cause problems
 ] >until every router had regenerated its LSP -- within 20 minutes using 
 ] >default
 ] >LSP regen timer.  See the 3-way draft for other problems that can happen
 ] >because of running IS-IS over an unreliable link.
 ] >
 ] >Jeff
 ] >
 ] >At 02:12 AM 1/24/2002, 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.
 ] > >
 ] > >"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.
 ] > >
 ] > >- 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
 ] > >
 ] 
 ] 
 ] 
 ] 
 ] _________________________________________________________________
 ] Chat with friends online, try MSN Messenger: http://messenger.msn.com
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list  -  [email-masked]
 ] http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: Dave Katz <[email-masked]>
Date: Fri, 25 Jan 2002 00:00:49 -0800 (PST)

We send 'em anyhow.  I think I made the cisco code do the same thing,
but it's been a lot of years.  Or maybe you can just configure it
on the cisco box, I don't remember offhand.

Cheap insurance when working with the ill-named mesh groups.

--Dave

---

From: Naiming Shen <[email-masked]>
Date: Fri, 25 Jan 2002 10:14:10 -0800

I was referring to how much useful if one send repeated resend CSNPs.
My understanding is: very little, why bother.

 ] Naiming Wrote:
 ] 
 ] > In the case no 3way hello is running, the first CSNP is lost, and
 ] > the link becomes unidirectional, no matter how many CSNPs being
 ] > sent later on, the two sides still can not syncronize, or it does get
 ] > syncronized but one side will keep sending out LSPs due to no Ack
 ] > back from the peer.

I think I had the second paragraph from 3way draft below in mind,
which is the link came up, the initial CSNP got lost and also the
link became unidirectional.

     ----->--- X ------
   A                    B
     -----<------------

in the above diagram, the connection from A to B is down, but from
B to A is up.

Assume both sides are out of sync.

1) A -> B initial csnp is lost

   well, the link is down, no matter how many CSNPs A trys to resend,
obviously they are wasted.

2) B -> A initial csnp is lost

   If B do not resend CSNP, A will try to send all its LSPs over the
broken link and get lost. If B do resend CSNPs, A will only try to
resend partial of its LSPs, and all get lost.

So it does not matter CSNPs get resend or not. Actually, if a link
is unidirectional, out sync maybe is better, since it can be
noticed by operators sooner.

If A and B has parallel links, then both sides are always synced,
assume the other link is ok, then resend or not of CSNP does not
matter either.

These days, one can hardly find any routers do not do 3way by
default, so its not a very interesting subject; for 3way draft,
it is THE subject.

 ] 
 ] >In the case of the link being bidirectional, the initial CSNP got lost.
 ] >All LSPs will be sent over the link, and the other side has to send back
 ] >the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A.
 ] >A has to response with PSNPs. Even A keeps sending csnps to B, A still
 ] >need to send those PSNPs. And they basically contain the same info: don't
 ] >send them anymore!

     ----->------------
   A                    B
     -----<------------

borrow the same diagram, only the link is good, bi-directional.
but this has no relation with the 3way draft.

If A -> B initial CSNP is lost. B has to send all its LSPs over this
link to A. Due to the Ack mechanism, A needs to send PSNPs to ack those
LSPs from B, or send its LSPs to B if they are more recent. This is
what A has to do after receiving LSPs from B. This is regardless of
B resend CSNPs to A or not. Which means those resent CSNPs are wasted.

The only time it seems to help for repeated resending CSNPs seems 
if both side initial CSNPs get lost, and also some of the LSPs
also get lost during the transmission. Then resend CSNPs can
reduce keep resending those lost LSPs which has no need to sync
on both sides in the first place. So its just an optimization.

That's why I suggested some "over-optimization" steps before
sending out your LSPs over this link:

- at link comes up, keep sending a couple of sets CSNP, hope
  at least one set gets through.

- have some kind of Ack for p2p initial CSNPs.

But this is not without a price to pay, obviously any one of
those will delay the sending out LSPs, which will delay the
network convergence.

 ] 
 ] Hi Naming, can you please explain the two scenarios above in more detail?
 ] Are they the same as the scenarios referenced in the "Three-Way Handshake
 ] for IS-IS Point-to-Point Adjacencies" draft as referenced below:
 ] 
 ]  Three failure modes are known. First, if the link goes down and then
 ]    comes back up, or one of the systems restarts, and the CSNP packet is
 ]    lost, and the network has a cut set of one through the link, the link
 ]    state databases on either side of the link will not synchronize for a
 ]    full LSP refresh period (up to eighteen hours).
 ] 
 ]    A second, more serious failure, is that if the link fails in only one
 ]    direction, the failure will only be detected by one of the systems.
 ]    Normally, this is not a serious issue; only one of the two systems
 ]    will announce the adjacency in its link state packets, and the SPF
 ]    algorithm will thus ignore the link. However, if there are two
 ]    parallel links between systems and one of them fails in one
 ]    direction, SPF will still calculate paths between the two systems,
 ]    and the system that does not notice the failure will attempt to pass
 ]    traffic down the failed link (in the direction that does not work).
 ] 
 ]    The third issue is that on some physical layers, the
 ]    interconnectivity between endpoints can change without causing a
 ]    link-layer-down condition. In this case, a system may receive packets
 ]    that are actually destined for a different system (or a different
 ]    link on the same system). The receiving system may end up thinking
 ]    that it has an adjacency with the remote system when in fact the
 ]    remote system is adjacent with a third system.
 ] 
 ] 
 ] Cheers,
 ] Ken Larmer
 ] CommSense Networks
 ] 
 ] 

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Fri, 25 Jan 2002 10:24:55 -0800

]    So I don't see any benefit to sending periodic CSNPs.  It was worth
 ]    considering, though.

Yes. I was just referring to the case at initial stage of syncing up, I don't
see a reason of lots of CSNPs flowing through.

But send them periodically, say once every 15 minutes may not be a
bad network insurance approach. Especially the router software is just
upgraded:-)

 ] 
 ] We send 'em anyhow.  I think I made the cisco code do the same thing,
 ] but it's been a lot of years.  Or maybe you can just configure it
 ] on the cisco box, I don't remember offhand.
 ] 
 ] Cheap insurance when working with the ill-named mesh groups.

Yes, its definitely recommended if the link is configured as
mesh-group blocking lsps. Then periodically exchange of CSNPs
over the p2p links makes lots of sense. But again, you were
the one created those problems at the first place...

 ] 
 ] --Dave

- Naiming

---

From: Tony Li <[email-masked]>
Date: Fri, 25 Jan 2002 11:29:13 -0800

|    So I don't see any benefit to sending periodic CSNPs.  It was worth
 |    considering, though.
 | 
 | We send 'em anyhow.  I think I made the cisco code do the same thing,
 | but it's been a lot of years.  Or maybe you can just configure it
 | on the cisco box, I don't remember offhand.
 | 
 | Cheap insurance when working with the ill-named mesh groups.

I'd say they're damn cheap insurance period.  But then I was always a belt
and suspenders kinda guy.

Tony

---

From: "Ken Larmer" <[email-masked]>
Date: Fri, 25 Jan 2002 10:06:21 -0500

>need to send those PSNPs. And they basically contain the same info: don't

Hi Naming, can you please explain the two scenarios above in more detail?
Are they the same as the scenarios referenced in the "Three-Way Handshake
for IS-IS Point-to-Point Adjacencies" draft as referenced below:

 Three failure modes are known. First, if the link goes down and then
   comes back up, or one of the systems restarts, and the CSNP packet is
   lost, and the network has a cut set of one through the link, the link
   state databases on either side of the link will not synchronize for a
   full LSP refresh period (up to eighteen hours).

   A second, more serious failure, is that if the link fails in only one
   direction, the failure will only be detected by one of the systems.
   Normally, this is not a serious issue; only one of the two systems
   will announce the adjacency in its link state packets, and the SPF
   algorithm will thus ignore the link. However, if there are two
   parallel links between systems and one of them fails in one
   direction, SPF will still calculate paths between the two systems,
   and the system that does not notice the failure will attempt to pass
   traffic down the failed link (in the direction that does not work).

   The third issue is that on some physical layers, the
   interconnectivity between endpoints can change without causing a
   link-layer-down condition. In this case, a system may receive packets
   that are actually destined for a different system (or a different
   link on the same system). The receiving system may end up thinking
   that it has an adjacency with the remote system when in fact the
   remote system is adjacent with a third system.

Cheers,
Ken Larmer
CommSense Networks

---

From: Jeff Learman <[email-masked]>
Date: Fri, 25 Jan 2002 10:05:49 -0500

>Cheap insurance when working with the ill-named mesh groups.

I bet you did this before 3-way handshake was proposed.  Without it,
systems would recover from a one-sided restart much more quickly than
waiting for all LSPs to be regenerated.  Even with 3-way, I can't
imagine them doing any harm.

Any system that runs IS-IS on an unreliable PTP link and does not support
3-way handshake would be strongly advised to send periodic CSNPs.

Regards,
Jeff

---

From: Dave Katz <[email-masked]>
Date: Fri, 25 Jan 2002 08:21:40 -0800 (PST)

Can't remember;  I'm old and doddering.  But they were intended to solve
separate problems.

Until the mid 90s, this described pretty much every deployed ISIS PTP
link, but somehow we all survived.  The case we were actually trying
to solve with the 3way hack was the one where there were two parallel
links between the same pair of routers, but only one of them came up
fully.  The half-up side would happily pump traffic down the link, and
the rest of the network would route to it (since the two links cannot
be distinguished from a distance) and much unhappiness resulted.  (In
the single link case, the SPF would fail to calculate a path through
the half-up link, so nobody would use it.)

--Dave