Hi Mitchell,
Agreed,
I rather not have a TCP style in OSPF graceful restart.

But I am talking about TCP Timeout, but an application
has already done much work to send data to end point, before
time out occurs.


I would rather have a  request reply mechanism , which is similar
to pinging end points, before actually beginning the signaling.

Which I have shown in the time line.

Stressing the point of only what I want before the irreversible restart.

Regards,
Abhay



----- Original Message -----
From: "Erblichs" <[EMAIL PROTECTED]>
To: "Abhay D.S" <[EMAIL PROTECTED]>
Cc: "Acee Lindem" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Saturday, October 20, 2007 4:02 PM
Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF
protocolQuestion


> Abhay D.S.,
>
> Sorry about the top post, but..
>
> TCP has a slow-start mechanism with ACK
> clocking to verify completion of xmit'ed data,
> until a threshold is met or,
>
> Until 2 or 3 DUP ACKs are seen and then
> rexmited or a coarse grain timeout occurs,
>
> However, TCP does not guarantee that the
> recvr will actually recieve data xmited
> by the send, just that if the data arrives
> then, it will send acks..
>
> And again, their is no guarantee that the
> acks will be recieved, so the sender can
> send more data.
>
> Mitchell Erblich
> -----------------
>
> > "Abhay D.S" wrote:
> >
> > Hello Acee,
> >
> > a) Restart complete variable poll is one method after restart
> >
> > I am trying to find a method before restart to be deterministic.
> >
> > A simple analogy in TCP.
> >
> > For example..in TCP, just after connection establishment, I want
> > start sending data, at the same time the remote link had some problem.
> >
> >
> > a) Scenario 1
> >
> > 0sec .....5 Sec...(ok).....10 Sec (ok).....15 Sec (ok).....[DONE]
> >
> > Continue restart y/n ? : y
> >
> > Attempting graceful restart.....
> >
> > [OK]
> >
> > b) Scenario 2
> >
> > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to
> > network conditions]
> >
> >
> > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec
> > (ok).....[DONE]
> >
> > Continue restart y/n ? : y
> >
> > Attempting graceful restart......
> >
> > [OK]
> >
> > c) Scenario 3
> >
> > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to
> > network conditions]
> >
> >
> > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (Wait a
> > While).....[Retrying due to network conditions]
> >
> > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to
> > network conditions]
> >
> > Continuing restart may affect forwarding...
> > Continue anyway ? y/n .....n
> >
> > [OK]
> >
> >
> > The time line above considers a network stable.
> >
> >
> > After the restart is done I can follow method a)
> >
> >
> > Thanks for your reply,
> > Regards,
> > Abhay
> >
> >
> >
> >
> >
> >
> >      ----- Original Message -----
> >      From: Acee Lindem
> >      To: Abhay D.S
> >      Cc: [email protected]
> >      Sent: Friday, October 19, 2007 9:13 PM
> >      Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for
> >      OSPF protocol Question
> >
> >      Hi Abhay,
> >      Most of this borders on the implementation of the networking
> >      equipment's in-service upgrade. For now, let's just assume
> >      that you have redundant data place connectivity for the new
> >      line cards and solely need do the graceful restarts as
> >      indicated below. Again, this borders more on implementation.
> >      However, now the OSPFv2 MIB as described in RFC 4750 does
> >      support a variable which could be polled to determine when
> >      restart on a given router has completed.
> >
> >       ospfRestartStatus OBJECT-TYPE
> >             SYNTAX       INTEGER { notRestarting (1),
> >                                    plannedRestart (2),
> >                                    unplannedRestart (3)
> >                                  }
> >             MAX-ACCESS   read-only
> >             STATUS       current
> >             DESCRIPTION
> >                "Current status of OSPF graceful restart."
> >             ::= { ospfGeneralGroup 21 }
> >
> >
> >      Hope this helps,
> >      Acee
> >
> >      On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote:
> >
> >     >  hi all,
> >     >
> >     >  Suppose I am providing real-time transactions over IP in a
> >     >  non NSR environment(I dont invest much on getting a backup
> >     >  RP i.e).
> >     >
> >     >  But I have NSF, owing to the ease of which OSPF can be
> >     >  used, I
> >     >  use OSPF to manage connections to WAN.
> >     >
> >     >  And I have bought new I/0 modules which require a restart
> >     >  for
> >     >  all my routers for proper installation.
> >     >
> >     >  Luckily, I have inservice upgrade on the boxes.
> >     >
> >     >  Assuming that I am a new operator without any
> >     >  certifications under
> >     >  my belt, I dont have a beautiful NMS with colored buttons.
> >     >
> >     >  But I must implement the new I/O cards and its features
> >     >  without disturbing
> >     >  the users who are using the network for routing
> >     >  transactions such as data
> >     >  backup over network or voice forwarding and other
> >     >  distributed applications
> >     >  running over TCP/IP using my network.
> >     >
> >     >  I want to graceful restart all my routers one by one,
> >     >  called as cascaded
> >     >  re-starts, how can I make sure the transition is done
> >     >  seamlessly.
> >     >
> >     >  I want the "this thing" to be automatic, since each router
> >     >  is graceful
> >     >  restarted
> >     >  and then then the next one is re-started and then the next
> >     >  one,
> >     >  automatically.
> >     >
> >     >  I can write a script to do that, but I am not sure the
> >     >  forwarding will be
> >     >  safe,
> >     >  because it is difficult to control the network transient
> >     >  conditions.
> >     >
> >     >  Any mechanism available ?.
> >     >
> >     >  Thanks and Regards,
> >     >  Abhay
> >     >
> >     >
> >     >
> >     >
> >     >  _______________________________________________
> >     >  OSPF mailing list
> >     >  [email protected]
> >     >  https://www1.ietf.org/mailman/listinfo/ospf
> >     >
> >
> >     ---------------------------------------------------------------
> > _______________________________________________
> > OSPF mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to