Subject: Re: Extended Hitless OSPF Restart

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 28 Jun 2002 07:32:28 -0400

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:[email-masked]]
Sent: Friday, June 28, 2002 12:18 AM
To: [email-masked]
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:[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: Daniel Gryniewicz <[email-masked]>
Date: Fri, 28 Jun 2002 12:27:20 -0400

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

---

From: Erblichs <[email-masked]>
Date: Fri, 28 Jun 2002 16:28:57 -0700

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

---

From: Acee Lindem <[email-masked]>
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

--
Acee