Re: Detecting Inactive Neighbors over OSPF - repost

[Vivek Dubey <[e-mail]>]

Hi Acee, Roy:

Section 3.0 in draft-ietf-ospf-hitless-restart-07.txt :
======================================================
"This means that Y's LSAs continue to list an adjacency
to X over network segment S,regardless of the adjacency's
current synchronization state. "

Section 2.1 draft-ietf-ospf-dc-06.txt
======================================
If no acknowledgement (explicit or implicit) is received for a
predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and should bring the
adjacency down.

Agreeing that "graceful restart" at helper
should "override" the Nbr dead, detected by
"Nbr probing" at helper.

But my concern was, this is not very clear from
draft itself.....implementors might miss it....
so it would be better if it is explicitly mentioned
somewhere.....

But leaving it to discretion of authors.

thanks,
vivek



-----Original Message-----
From: Mailing List [mailto:[e-mail]]On Behalf Of Acee
Lindem
Sent: Friday, 6 June 2003 2:45 AM
To: [e-mail]
Subject: Re: Detecting Inactive Neighbors over OSPF - repost


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

***************************************************************************
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.
***************************************************************************