Hi Acee,

From what I understand about John's implementation,
helper neighbor should not exit helper mode even though
restarting router's dead interval expires. It should continue
to list restarting router in its LSA as if the adjacency is full.
The only case it should exit helper mode is when grace period
expires, topology changes or if it receives max-age grace LSA
from the restarting router. Thanks.

Kent Wong

>From: Acee Lindem <aceeREDBACK.COM>
>Reply-To: Mailing List <OSPFDISCUSS.MICROSOFT.COM>
>To: OSPFDISCUSS.MICROSOFT.COM
>Subject: Re: Extended Hitless OSPF Restart
>Date: Fri, 28 Jun 2002 16:37:52 -0700
>
>Daniel, Michell,
>
>I'll take a look at John's public domain implementation to see
>what he does. Perhaps, the intent is to allow the neighbor
>relationship to go all the way down but preserve the
>neighbor and continue advertising it as if it were full. If that is
>the case, I agree that it is unnecessary. I will probably maintain
>the local policy to allow one to configure helper mode rejection if
>the grace-period strictly exceeds the router-dead interval.
>
>Thanks,
>Acee
>
>Erblichs wrote:
> >
> > Daniel,
> >
> > I completely agree with Daniel's statement that the extension is
> > unnecessary..
> >
> > However, "the helping relationship" could be considered
> > ambiguous..
> >
> > Vishwas,
> >
> > 1) Yes. I understand that was the orignal intent.
> >
> > However, if
> > we go back into the "wants" wording of that one section. And
> > the restarting router does not want, and the BDR does not
> > acknowledge, then the BDR after not seeing hellos from the
> > DR will do a re-election. In my opinion, if I understand the
> > doc, wants should be changed to a MUST and if all neigbors
> > (full adjs) do not ack, then the hitless restart must be
> > terminated...
> >
> > 2) No. Again, if the restart router does not "want". Please
> > READ what it says in section 2.1, with the line "If
> > Router X wants to ensure that .... Then the BDR does
> > not have to ack the grace-LSAs..
> >
> > If we look at section 4, we don't know if the grace-LSA
> > was ever recv'd because we could have gone down before
> > we recv'd the ack. Because we didn't want to re-xmit.
> >
> > If the restart router restarts before the router-dead interval
>has
> > expired, then the section's 4, will still be valid. And
> > we will still see the the links to X. See section 4. So,
> > again, this invalidates the requirement of it being a
> > required helper.
> >
> > 3) What.... The only limit is... 3.1 Local policy..
> > "b) never allow the grace period to exceed", how
> > many bits do we have to specify a grace period?
> > Where does the grace-LSA's TLV limit us to 1 hr
> > as a magical value? I see 4 bytes of length specified
> > as a limit for the grace period. I think that limit
> > is bit more than 1hr...
> >
> > 4. skip 4.. You agree... :-)
> >
> > 5). Nooo... "this goes back to the understanding of
> > "the helping relationship". I see it for the
> > full grace period of a max 32 bits of seconds.
> > Years... I just asked to limit it to 1 hr..
> > So, a length of 2 bytes should be more than
> > sufficent as a max of I think 18 hours or so..
> >
> > Mitchell Erblich
> > ================================
> >
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > The draft says:
> > >
> > > The helper relationship is per network segment. As a "helper
> > > neighbor" on a segment S for a restarting router X, router Y has
> > > several duties. It monitors the network for topology changes, and
>as
> > > long as there are none, continues to its advertise its LSAs as if
>X
> > > had remained in continuous OSPF operation. 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. This
> > > logic affects the contents of both router-LSAs and network-LSAs,
>and
> > > also depends on the type of network segment S (see Sections
>12.4.1.1
> > > through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over
>a
> > > virtual link, the helper must also continue to set bit V in its
> > > router-LSA for the virtual link's transit area (Section 12.4.1 of
> > > [Ref1]).
> > >
> > > Also, if X was the Designated Router on network segment S when the
> > > helping relationship began, Y maintains X as Designated router
>until
> > > the helping relationship is terminated.
> > >
> > > This implies to me that the adjacency *SHOULD NOT TIME OUT* regardless
>of the
> > > lack of hellos until the grace period is over. Am I wrong in this?
>If I'm
> > > right, then the extension is unnessary. If I'm wrong, the draft
>should
> > > probably say so. What I interpret a Grace LSA to mean is: "Put the
>adjacency
> > > on hold for X seconds. Please." If you time out the adjacency, but
>don't
> > > tell anyone, then do you un-time-out the adjacnecy when the router
>comes back
> > > up? Do you exit the helper mode when the hold timer expires even
>though the
> > > grace timer has not expired? That's a violation of the draft,
>certainly.
> > >
> > > Daniel
> > >
> > > On Fri, 28 Jun 2002 07:32:28 -0400
> > > "Manral, Vishwas" <VishwasMNETPLANE.COM> wrote:
> > >
> > > > Hi Mitchell,
> > > >
> > > > 1. When something is not stated in a draft like the BDR operation,
>it means
> > > > there is no change in the way we need to work. John has stated in
>previous
> > > > mails.
> > > >
> > > > 2. It is assumed when the BDR or any other router isn't a helper,
>the
> > > > non-helper router would cause the hitless restart to exit when the
> > > > restarting router comes up. So the operation from there is the same
>as
> > > > specified in the base RFC.
> > > >
> > > > 3. The grace period will never be one hour(atleast as I see it).
> > > >
> > > > 4. I agree to the assumption that the DR is kept is not explicitly
>stated.
> > > > However in Section 2 it is stated that the restarting router will
>re-elect
> > > > itself the DR if it was the DR before restart. Also the assumption
>that a
> > > > high hitless restart interval would be of no use if we had a small
>router
> > > > dead interval in which we could not even send hellos and we broke
> > > > adjacencies because of that, can lead to the conclusion that we will
>not
> > > > break adjacencies.
> > > >
> > > > 5. As stated above we need to send a hello before the router dead
>interval,
> > > > so the router dead interval needs to be large enough that we are
>able to do
> > > > restart and send a hello even if we do not complete the hitless
>restart by
> > > > then.
> > > >
> > > > Acee,
> > > >
> > > > So would we want a different TLV for this, rather than a different
>reason(as
> > > > the times we are talking about are different. Point 5. above), if we
>assume
> > > > that the draft assumption of strict checking and not resetting the
> > > > inactivity timer.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Erblichs [mailto:erblichsEARTHLINK.NET]
> > > > Sent: Friday, June 28, 2002 12:18 AM
> > > > To: OSPFDISCUSS.MICROSOFT.COM
> > > > Subject: Re: Extended Hitless OSPF Restart
> > > >
> > > >
> > > > Vishwas,
> > > >
> > > > Looooong....
> > > >
> > > > Here are what I percieve as real weaknesses in the two
>docs..
> > > >
> > > > Actually no it doesn't state that the DR is kept between
>restarts.
> > > > It implicitly states that the DR is kept if the router was
>down for
> > > > less than router dead interval. Actually down for time of (
>router
> > > > dead interval - waiting time) or less, by seeing a hello
>with the
> > > > restart router being specified as the DR. But then there is
>a
> > > > conflicting
> > > > statement, which I will point to later..
> > > >
> > > > And I am going blind, I see no mention of how a BDR is
>treated
> > > > in either restart doc. So, it is unstated operation. What
>happens
> > > > if the BDR is a helper, should it not re-elect itself due to
> > > > section 3 as a helper to maintain the X router as the DR? If
> > > > the BDR isn't a helper (router did not want to verify that
>the
> > > > grace-LSAs were recieved), does the BDR then ignore the
>helper's
> > > > hellos
> > > > (assuming that DRothers are helpers and the restart was the
>DR) sees
> > > > that
> > > > there is no DR hellos, his router dead interval expires, and
>elect
> > > > himself?
> > > > Now lets assume that the BDR came up after the DR, but
>really has
> > > > higher
> > > > priority. Again the interaction is unspecified when the
>restart
> > > > router
> > > > comes back. However, between the time that the BDR elected
>himself,
> > > > and
> > > > the helpers keep the restart as the DR, we will have two DRs
> > > > specified
> > > > in hellos... ummm Now to make things worse, a new router
>comes up
> > > > and
> > > > looks for a DR and sees different routers, continually
>announcing
> > > > different
> > > > routers as the DR..
> > > >
> > > > Justification for the problems are stated in long form
>below...
> > > >
> > > > Please note that point 1 below identifies a statement,
>identifies
> > > > problems with it, and then sees that in point 2 a
>conflicting
> > > > statement that implictly specifies increasing the
> > > > router-dead-interval
> > > > to the grace interval.
> > > >
> > > > New Point 1
> > > > ============
> > > >
> > > > Sect. 2 After the router restarts ...(3) If the restarting
>router...
> > > >
> > > > "an Hello packet is
> > > > received from a neighbor listing the router as Designated
> > > > Router."
> > > >
> > > > But if the restarting router is down for more than the dead
>router
> > > > interval., will hellos still specifiy that the restarting
>router
> > > > is the DR? They shouldn't. Why can't the router see that a
>DR
> > > > is Y, and Y's hellos specify that its priority is Z, then
>specify
> > > > its own priority as Z+1, and act that it is the DR. And
>force a
> > > > re-election back to itself as the DR? Why wouldn't it want
>to do
> > > > that? Should this last item be a "MAY", meaning a DR
>restarting
> > > > for longer than router dead interval may relect itself by
>doing
> > > > the following..
> > > >
> > > > Orig Doc,..
> > > > If the restarting router is kept as the DR, then what
>happens to the
> > > > routers that come up sometime
> > > > before it re-elects itself? I am concerned most where a BDR
>doesn't
> > > > exist. They are effectively dead. They can't form
>adjacencies until
> > > > there is a live DR.
> > > >
> > > > This problem is worse with the "extended hitless" . Section
>3.
> > > > Changes
> > > > to helper neighbor operation
> > > >
> > > > Where the router dead interval is reset to the grace
>period....
> > > > Wow..
> > > > What happens if that time is 1 hour and there is no BDR, and
>other
> > > > routers come up, no adjs are formed. Why can't you just keep
>the
> > > > original router dead interval time, mark the router in a
>restart
> > > > state,
> > > > and if the router doesn't come back in say 1 hr, then
>cleanup..
> > > > Restart
> > > > state says don't send him anything other than hellos,
>suspend your
> > > > re-xmits to that router, etc...
> > > > This would decrease the load on the routers that stay up.
> > > >
> > > > extend doc..If the restarting router is the DR.......
> > > > At least there should be a BDR verified for the interfaces
>where
> > > > there
> > > > there is a DR, else.. it should NOT be extended in my
>opinion. If
> > > > there
> > > > is a BDR and the BDR goes down the helpers should revert to
>their
> > > > previous dead interval times, and re-elect.
> > > > extend doc.. And what happens to the negotiated hello dead
>interval
> > > > time value with exchange of hellos pdus?
> > > >
> > > >
> > > > New Point 2
> > > > ================
> > > > But after all of that...
> > > > We know have a conflicting statement... of section 2... with
> > > > hellos..
> > > > 3. Operations of helper neighbor..
> > > >
> > > > "Also, if X was the Designated Router on network segment S
>when the
> > > > helping relationship began, Y maintains X as Designated router
>until
> > > > the helping relationship is terminated."
> > > >
> > > > This is for the grace period...
> > > >
> > > > Or does this implictly state that "dead router interval" is
> > > > automaticly
> > > > extended to the grace period", by the helpers. IT should now
>be
> > > > sending
> > > > hellos out with the restart system as the DR...
> > > >
> > > > If that was so, then why would the extended doc need to
>explicitly
> > > > state that???????
> > > >
> > > > Why is there a conflict with the two docs..
> > > >
> > > >
> > > > OLD POINTS
> > > > ==================
> > > >
> > > > And back to a question that I had over a month ago.
> > > > 2.1 Entering hitless restart...
> > > >
> > > > "If Router X wants to ensure that its neighbors
> > > > receive the grace-LSAs, it should retransmit the grace-LSAs
> > > > until they are acknowledged (i.e, perform standard OSPF
>reliable
> > > > flooding of the grace-LSAs). If one or more fully adjacent
> > > > neighbors do not receive grace-LSAs, they will more than
>likely
> > > > cause premature termination of the hitless restart procedure
> > > > (see Section 4)."
> > > >
> > > > 1st: Is "wants" a SHOULD, MUST, ...??
> > > >
> > > >
> > > > Sub item
> > > > ========
> > > > Lets assume it is a must. What happens if just one nbr
>has a
> > > > late
> > > > ack?
> > > > And now that the late ack, now shortens the time
>allocated for
> > > > "requested grace period"? I assume he can extended it by
> > > > "There is one exception to the above requirements. If Y
>was
> > > > already helping X on the associated network segment, the
>new
> > > > grace-LSA should be accepted and the grace period should
>be
> > > > updated accordingly."
> > > > ***But how does he withdraw it?
> > > > Should he send a grace-LSA with a grace-period of
>0?
> > > >
> > > >
> > > > 2nd: Is "recieve", acked?
> > > >
> > > > This one paragraph is a conflict in itself.
> > > >
> > > > First if we see "wants" as
> > > > a MUST, then we don't get acks from an adj nbr, then we
>prematurely
> > > > terminate if we don't get back acks.
> > > >
> > > > 2nd if we see "wants" as optional, and we don't verify that
>they
> > > > recv
> > > > the grace-LSA, then then we we don't care that some systems
>are
> > > > unaware
> > > > of what we are doing?
> > > >
> > > > If he thinks that all of our router neighbors should agree
>with us,
> > > > and there is a router neighbor addition, then his implied
>statement
> > > > should prematurely end the helper agreement? Else, not..
> > > >
> > > > So, what is he saying, again...
> > > > If we look at section 4. Backward compatibility
> > > > Then he states
> > > > "If one or more
> > > > neighbors of a router requesting hitless restart are unmodified,
>or
> > > > if they do not received the grace-LSA, the hitless restart
>converts
> > > > to a normal OSPF restart."
> > > >
> > > > Which is no longer a want... because of "recvieved the
>grace-LSAs"?
> > > > *** But what happens if a router doesn't want to verify that
>his
> > > > grace-LSAs
> > > > are recvd?
> > > >
> > > >
> > > >
> > > > Mitchell Erblich
> > > > ==================
> > > >
> > > >
> > > >
> > > > "Manral, Vishwas" wrote:
> > > > >
> > > > > Hi Mitchell,
> > > > >
> > > > > Please look at the draft
> > > > >
> > > >
>https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> > > > > this draft clearly states the DR role stays after across a hitless
> > > > restart,
> > > > > while we do not keep the BDR role.
> > > > >
> > > > > As long as we do not reset adjacencies(neighbor change event) with
>the
> > > > > restarting router we will not do a DR election at all.
> > > > >
> > > > > Thanks,
> > > > > Vishwas
> > > > >
> > > > > -----Original Message-----
> > > > > From: Erblichs [mailto:erblichsEARTHLINK.NET]
> > > > > Sent: Thursday, June 27, 2002 2:04 AM
> > > > > To: OSPFDISCUSS.MICROSOFT.COM
> > > > > Subject: Re: Extended Hitless OSPF Restart
> > > > >
> > > > > Sorry group,
> > > > >
> > > > > For this document...
> > > > >
> > > > > For the restarting router.. If it was the DR or BDR, do
> > > > > we keep him as the old DR/BDR or re-elect after router
> > > > > dead interval?
> > > > >
> > > > > Mitchell Erblich
> > > > > ==================
> > > > >
> > > > > Erblichs wrote:
> > > > > >
> > > > > > Group,
> > > > > >
> > > > > > This really goes back to the original doc..
> > > > > >
> > > > > > Shouldn't there be a limit of say 1 hour for the grace
>period.
> > > > > >
> > > > > > After that time, work that the proposed router's/helpers
> > > > > > should almost ignore that the hitless restart
>functionality
> > > > > > was originally requested and age out the LSAs that were
> > > > > > originated by the by the restarting router.
> > > > > >
> > > > > > Mitchell Erblich
> > > > > > =======================
> > > > > >
> > > > > > Daniel Gryniewicz wrote:
> > > > > > >
> > > > > > > Hi.
> > > > > > >
> > > > > > > Could someone please explain to me why this is necessary? My
>reading
> > > > of
> > > > > > > draft-ietf-ospf-hitless-restart-02 indicates that an
>implementation
> > > > > should
> > > > > > > *not* exit helper status because a router dead interval
>expired.
> > > > Please
> > > > > > > enlighten me.
> > > > > > >
> > > > > > > Daniel
> > > > > > >
> > > > > > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > > > > > Acee Lindem <aceeREDBACK.COM> wrote:
> > > > > > >
> > > > > > > > FYI - Ultimately, this would be an informational RFC or
>better yet
> > > > > > > > folded into the base "OSPF Hitless Restart" specification
>(although
> > > > > > > > this has not been discussed as of yet).
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Acee
>
>--
>Acee

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]