|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Manral, Vishwas (VishwasM_at_NETPLANE.COM)
Date: Tue Oct 22 2002 - 12:48:14 CDT
Hi Acee,
I agree to Padma's statement that we are using link-local LSA to signal
hitless-restart, because we would not want the LSA to be flooded by the
neighbors into the area. We are signalling router parameters in the link
local LSA.
Regarding 2.
- I think we should update the grace-period/reason only when we have a
change in content of the Grace LSA from the neighbor to the restarting
router on any interface. So if we get a different value of
grace-period/restart reason we update and restart the grace period on the
helper else we do not. This would be in keeping with Section 3 of the draft.
- I think the first grace LSA withdrawn would cause the router to exit
hitless restart mode for that neighbor.
Thanks,
Vishwas
-----Original Message-----
From: Acee Lindem [mailto:acee
REDBACK.COM]
Sent: Tuesday, October 22, 2002 8:22 PM
To: OSPF
DISCUSS.MICROSOFT.COM
Subject: Re: Hitless restart
All,
I think we have a "rough concensus" that the restarting router
should NOT try to optimize flooding of grace LSAs. I've
only had one vote for this and I believe the vote was more
for flooding optimizations in general than this particular
scenario.
Padma,
I don't think it simplifies the helper code (or specification)
to apply the grace LSA to all neighbor instances of restarting
router. Here are my reasons:
1. Conceptually, I don't think it is right to apply the link
local grace LSA to neighbors that are not on the link.
2. There are simply more corner cases -
- When you receive a second grace LSA from the restarting
router, do you update the reason and grace period for
all neighbor instances or only ones on that segment?
- When do exit helper mode? Is it when the first grace
LSA is withdrawn or all the grace LSAs? I certainly don't
think there should be disconnect between entering and
exiting helper mode.
I do agree that it is somewhat more robust for the case where
you are adjacent with the same router on more than one link.
However, I don't see this as a real big gain. Has anyone
else implemented this draft?
Thanks,
Acee
Padma Pillay-Esnault wrote:
> Rajesh
>
>
> Rajesh Varadarajan wrote:
>
>>Acee, Padma,
>>
>
> <snip>
>
>>>>>>I do think it simplifies things if a restarting router originates the
grace LSAs
>>>>>>on all it's interfaces (or at least all with full neighbor
>>>>>>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>>>>>
>>>>>>adjacencies if it a planned restart).
>>>>>>
>
>>>>>>
>>>>>>
>>>>>>
>>
>>The above statement seems to imply (my reading) that a restarting router
>>
>>can only send Grace LSA's out of some (not all) of its interfaces. The
>>
> It doesn't imply that - clearly we send to all our neighbors.
>
> Padma
>
>>
>>spec however requires the router to send the grace-lsa out of all
>>interfaces on which it has full neigbhors. Failure to do so would always
>>result in its helper mode being terminated by others.
>>
> <snip>
>
>>>>>I also agree with you .. that's what I do - the restarting router sends
>>>>>grace lsa over all interfaces. But from a Helping router perspective
>>>>>we should do as in 00-txt. It simplifies the helper code.
>>>>>It also prevents corner cases where we might not help all adjacencies
>>>>>(when we should).
>>>>>
>>>>>Padma
>>>>>
>>>>
>>>>I haven't heard anyone object to why the 00-txt.
>>>>
>>>
>>>I will - I specifically agree with
>>>
>>>
>>>
>>> Note that Router Y only needs to receive a single grace-LSA from
>>> X, even if X and Y attach to multiple common segments.
>>>
>>>I don't like using an LSA with link local scope to enter/terminate
>>>helper mode for neighbors on different interfaces. It is better if the
>>>link local grace LSA only applies to that link.
>>>
>>
>>Given the behavior above, I think the each neighbor should be considered
>>independently on a segment by segment basis.
>>
>>
>>thanks,
>>rajesh
>>
>>
>
-- Acee
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]