|
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: Thu Oct 24 2002 - 06:26:21 CDT
Hi Acee/Don,
> Finally, there was also a previous discussion I was involved
> in regarding contraining the grace period to a max value of
> MaxAge (3600). Is this being included in the new draft?
I think MaxAge is a best case value. An LSA originated x minutes before
restart would be MaxAged after (MaxAge - x) time. As the maximum value of x
can be RefreshInterval, an ideal value would be closer to lesser than
(MaxAge - RefreshInterval), otherwise there would be large chances of the
hitless restart being a normal restart. (The MaxAgeDiff value would cancel
out.)
I think to make the graceful-restart spec match existing implementations, we
should allow an option of a "non-strict check" for the helper deciding to
exit restart.
Besides in the strict check case we could add the
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0203&L=ospf&T=0&F=&S=&
P=1902
Also as the only change to the draft for OSPFv3 part would be defining a new
LSA type, do we intend to describe it here in this draft itself?
Thanks,
Vishwas
-----Original Message-----
From: Acee Lindem [mailto:acee
REDBACK.COM]
Sent: Thursday, October 24, 2002 9:31 AM
To: OSPF
DISCUSS.MICROSOFT.COM
Subject: Re: Hitless restart
Hi Don,
Don Goodspeed wrote:
> Acee,
>
> On the issue of updating the grace period, I would only
> update in case the reason code changed, and changed to
> a value of unknown (and/or we could add a new "unplanned
> restart" reason code).
I'm not sure there is any difference between unknown
and unplanned.
>
> Also, I remember a while back a discussion on the list
> between yourself, Padma, and John regarding the IP address
> field in the Grace LSA. I cannot remember the specific issue,
> but I assume there's been a resolution (or at least an
> understanding)?
This was the comment that Padma made that the IP interface
address TLV is not necessary to identify the restarting
neighbor on multi-access (broadcast and NBMA) links. I pointed out
that it wasn't really necessary since the grace LSA was already
scoped to an OSPF interface and there could only be one
neighbor adjacency corresponding to the router ID (even if
one was running OSPF on more than one subnet). John pointed
out that OSPFv2 always uses the IP interface address to identify
neighboring routers on multi-access networks so it should
included to be consistent with the RFC 2328 (numerous sections).
I tend to agree with this and would vote to leave it in.
However, it is not needed for OSPFv3 since here neighboring
routers are always identified by router ID.
>
> Finally, there was also a previous discussion I was involved
> in regarding contraining the grace period to a max value of
> MaxAge (3600). Is this being included in the new draft?
That could be documented.
>
> Thanks,
> Don
>
> --- On Tue 10/22, Acee Lindem wrote:
> From: Acee Lindem [mailto: acee
REDBACK.COM]
> To: OSPF
DISCUSS.MICROSOFT.COM
> Date: Tue, 22 Oct 2002 14:49:37 -0400
> Subject: Re: Hitless restart
>
>
>>Manral, Vishwas wrote:
>>
>>
>>>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.
>>
>>
>>Vishwas,
>>
>>I agree that if we do agree to change the existing specification than we
>>should, in fact, honor changes to the grace-period/restart-reason. One
>>of my concerns with this approach is the added complexity (consider
>>determining which of multiple link local LSAs received on different
>>links is more recent).
>>
>>Thanks,
>>
>>Acee
>>
>>
>>
>>>- 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,
>>>>>
>>>>>
>>>>>
>>>>
>>>>>>>>>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.
>>>>>
>>>>>
>>>>>
>>>>
>>>>>>>>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
>>>--
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]