Re: Detecting Inactive Neighbors over OSPF - repost

[Acee Lindem <[e-mail]>]

Abhay Roy wrote:
> Vivek,
>
> I discussed this with my co-authors.. And we think that this
> should work just fine if the router supports (and is doing)
> graceful restart..
>
> The Grace LSA tells us to continue announcing the adjacency even
> if it goes down. The restarting router will _reset_ its
> adjacencies anyways, and we are going to see this. If the probe
> goes out and fails before, the grace period should cover it.


Roy,

I was meaning to make the same point but got tied up today.

Vivek,

Look at section 3.0 in draft-ietf-ospf-hitless-restart-07.txt. Note
that the neighbor going to DOWN state doesn't necessary cause
the helper to exit graceful restart.

Thanks,
Acee


>
> Regards,
> -Roy-
>
> On 06/05/03+0530 at 4:45pm, Vivek Dubey writes:
>
>
>>if lost in flood of mails ......
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:[e-mail]]On Behalf Of Vivek
>>Dubey
>>Sent: Saturday, 31 May 2003 12:43 PM
>>To: [e-mail]
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Roy,
>>Adjacency will be restored up again but
>>won't the purpose of "graceful restart" somewhat
>>defeated then (NBR is needlessly considered dead -
>>though it is trying graceful restart).
>>
>>Won't it be better, if it is explicitly mentioned:
>>1)Generally graceful restart techniques should finish well before
>>  the probe retries (configurable) are finished(as you said in reply).
>>OR
>>2)If the router has received grace LSA from other end
>>  point.... delay "Nbr probing" till "graceful restart"
>>  process completes.
>>
>>thanks,
>>vivek
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:[e-mail]]On Behalf Of Abhay
>>Roy
>>Sent: Saturday, 31 May 2003 1:17 AM
>>To: [e-mail]
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Vivek,
>>
>>Generally graceful restart techniques should finish well before
>>the probe retries (configurable) are finished. If it does not,
>>then yes, we will consider the neighbor dead. But it's not a big
>>problem, because the adjacency will come right back up.
>>
>>I guess implementations could choose to factor in the grace period
>>to 'delay' probes.
>>
>>Regards,
>>-Roy-
>>
>>On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:
>>
>>
>>>Roy,
>>>Suppose the time "Nbr probing" starts, the Ospf at the
>>>other end is undergoing "graceful restart"...(grace period
>>>1800 sec).....
>>>while probing fails at this end.....
>>>should we consdier NBR dead or there is some "safeguard"
>>>in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.
>>>
>>>
>>>
>>>thanks,
>>>vivek
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Mailing List [mailto:[e-mail]]On Behalf Of Abhay
>>>Roy
>>>Sent: Friday, 30 May 2003 2:06 PM
>>>To: [e-mail]
>>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>>Demand
>>>
>>>
>>>Mitchell,
>>>
>>>The important point to note here is that: If the originator is
>>>'reachable', DoNotAge LSA's can stay forever.
>>>
>>>Regards,
>>>-Roy-
>>>
>>>On 05/30/03-0700 at 12:20am, Erblichs writes:
>>>
>>>
>>>>Lets cover two stones with one throw..
>>>>
>>>>        Lets try part of this again..
>>>>
>>>>        In the 1793 RFC which deals with demand circuits,
>>>>        there is a 2.3 - 2) section that mentions MaxAge
>>>>        seconds, aka 3600 seconds or 1 hr.
>>>>
>>>>To ensure that these LSAs are eventually
>>>>      flushed from the routing domain, and that the size of the link
>>>>      state database doesn't grow without bound, routers are required to
>>>>      flush a DoNotAge LSA if BOTH of the following conditions are met:
>>>>
>>>>(2) The originator of the LSA has been unreachable (according to
>>>>    the routing calculations specified by Section 16 of [1]) for
>>>>            at least MaxAge seconds.
>>>>
>>>>        If probe exceeds 1 hr then LSAs are most likely
>>>>        dropped and LSAs need to be originated. Thus, tell
>>>>        me why you would want to allow LSAs to be forced
>>>>        to be re-originated in favor of a longer probe.
>>>>
>>>>        I also think you may get a dead nbr, but that is
>>>>        a different discussion point..
>>>>
>>>>        Mitchell Erblich
>>>>        Sr Software Engineer
>>>>        ---------------------
>>>>
>>>>
>>>>Mitchell,
>>>>
>>>>In case of 'always up' DC links, it does turn out to be periodic
>>>>probing. But in case of 'on demand' DC links, (if there is no data
>>>>traffic) it's of no use to bring up the link just to send probes.
>>>>So it makes sense to piggy back this event on the link coming up
>>>>event, and keep doing it periodically till the time line remains
>>>>up (due to data traffic).
>>>>
>>>>Regards,
>>>>-Roy-
>>>>
>>>>
>>>>
>>>>Abhay Roy wrote:
>>>>
>>>>>Mitchell,
>>>>>
>>>>>Why it MUST not exceed 1hr? Today it's infinity, so in theory any
>>>>>interval (including absurdly high ones) should be allowed.
>>>>>
>>>>>Regards,
>>>>>-Roy-
>>>>>
>>>>>On 05/28/03-0700 at 1:06pm, Erblichs writes:
>>>>>
>>>>>
>>>>>>Sorry group,
>>>>>>
>>>>>>        I forgot..
>>>>>>
>>>>>>        E) If ..ProbeInterval is kept, its max value MUST not exceed
>>>>>>           1 hr..
>>>>>>
>>>>>>        I think this follows that if we haven't heard from our
>>>>>>        nbr in 1 hr "he" is considered dead.
>>>>>>
>>>>>>        Mitchell Erblich
>>>>>>        -------------------
>>>>>
>>>
>>***************************************************************************
>>
>>>This message is proprietary to Future Software Limited (FSL)
>>>and is intended solely for the use of the individual to whom it
>>>is addressed. It may contain  privileged or confidential information
>>>and should not be circulated or used for any purpose other than for
>>>what it is intended.
>>>
>>>If you have received this message in error, please notify the
>>>originator immediately. If you are not the intended recipient,
>>>you are notified that you are strictly prohibited from using,
>>>copying, altering, or disclosing the contents of this message.
>>>FSL accepts no responsibility for loss or damage arising from
>>>the use of the information transmitted by this email including
>>>damage from virus.
>>>
>>
>>***************************************************************************
>>
>>***************************************************************************
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>***************************************************************************
>>
>>***************************************************************************
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>***************************************************************************
>>
>
>


--
Acee