Subject: Re: Extended Hitless OSPF Restart

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 27 Jun 2002 01:02:18 -0400

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:[email-masked]]
Sent: Thursday, June 27, 2002 2:04 AM
To: [email-masked]
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 <[email-masked]> 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
> > >

---

From: Erblichs <[email-masked]>
Date: Thu, 27 Jun 2002 11:48:10 -0700

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
        ==================