Subject: Re: another appoach to OOB LSDB Resynchronization??

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 2 Oct 2002 03:10:34 -0400

Hi Mitchell,

The draft is an individual submission and is located at
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt

I am however not too sure how you intend to achieve LSDB resynch without
changing the topology view of the network, because when we get a 1-way
received event we clear all the LS Retransmit List, DB summary list and Link
state request list and goto "Init" state. Are you saying we dont handle the
1-way received event at all? How will the neighbor know when its doing LSDB
resynch and when its not? I would be averse to any change in the FSM though.

A much simpler way to force an LSDB synch however would be to simply start
DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch
event). This would bring the adjacencies to Exstart state(and not to Init as
it would in case of 1-way received), however the topology data would change.
We could as well not change topology if we get SeqNumberMismatch in all
cases for the SeqNumberMismatch event, however I think it would be a major
deviation from the OSPF protocol.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Tuesday, October 01, 2002 11:16 PM
To: [email-masked]
Subject: another appoach to OOB LSDB Resynchronization??

Group,

        I haven't seen whether last year's RFC on Out-of-band
        LSDB Resynchronization draft had been formalized into a
        standardized RFC.

        So these comments may be way late, with this
        different approach to perform LSDB Resynchronization.

        I haven't tried this .... but in my mind this
        method could accomplish the same thing with
        legacy routers and remove the need for a
        option bit which is becoming a scarse thing
        in version 2. And be a lightweight mechanism.

        Since the neighbor field in a hello PDU is the
        normal indicator of 2-way communication, why
        not just temporarily drop the neighbor field
        of the adjacency that you wish to re-establish?

        Yes, I am assuming that based on your internal
        request to perform this operation you reset
        your neighbor state machine and set a internal
        "OOB request neighbor field flag".

        At best you can re-establish the link on average
        of 1/2 hello interval and at worst you will have
        to wait router-dead-interval timeframe before
        you re-acknowledge the arrival of hellos from
        the neighbor that you wish resync the adjacency.
        (or wait before you resend hellos?)

        The preference is to just with-hold the neighbor
        from the neighbor field. This would allow the
        OOB requester to remain as a DR or BDR if that
        was his orignal router OSPF type. This would
        remove any necessary overhead of elections,
        adjacency reformations, and substantial SPF
        calculations.

        Then the question is how to utilize the flag
        to make sure that you don't deallocate any
        neighbor data structures and whether you increment
        the sequence number of your orignated LSAs,
        keep them the same, or set MAXAGE and then resend.
        More than likely you will also have to withold
        flooding to the neighbor or acks back to the
        neighbor from his flooding of LSAs. If LSAs were
        recv'ed from the neighbor during flooding, I would
        probably incorporate them into my LSDB.

        Independent of how you deal with the above issues,
        you then must re-attempt to synchronize the LSDB.
        Assuming that their were more than two OSPF speaking
        routers in your area, your previous interaction should
        have minimal effects on your neighbor. More than
        likely, he had kept your earlier originated LSAs
        in his database. And you just resync, upon reaching
        full state again with the neighbor, you clear your
        internal "OOB request neighbor field flag".

        Is there a dual-behaviour (one who wants to redo the
        initial LSDB synchronization and one who keeps the
        established adj) achieved by establishing
        a adjacency and then removing the neighbor specified
        in the hello field that really requires the
        OOB requestor in the scenario to cycle into a
        period of router-dead-interval before sending out
        new hellos AND ... ????

        Flames now allowed....

        Mitchell Erblich
        ==========================

---

From: Erblichs <[email-masked]>
Date: Thu, 3 Oct 2002 18:30:07 -0700

Vishwas,

        Vishwas, I think there is significantly more work in your
        implimentation than doing what I suggested.

        *** My approach is to fit within the
        understanding of the OSPF protocol.

        And was a "clean slate appoach".

        The temporarily dropping the neighbor field
        and moving to 1-way suggestion is to fit into
        the original concept of the neighbor state
        machine.

        This is a neighbor state machine event.

        Once that particular hello PDU is sent, the
        next hello would then include the "missing
        neighbor field".

        This again is another neighbor state machine
        event.

        Due to the fact, that I have assumed that full
        adjacency has already been reached, then the
        retransmit and the requests lists should be
        empty. Yes, the neighbor timers will restart, etc..

        However, any neighbor state other than full
        state should be applicable for this type of
        change.

        Via the state machine, we should then be able
        to exchange Database Description packets. We then
        can build whatever lists that are then required
        via our normal process to re-synch the our
        LSDBs.

        *** All of this was to suggest
        there is no reason to consume a option bit for
        the reason of the draft RFC.

        One reason why might want to resync?? Lets say
        we have one or more DNA LSAs that were originated
        by someone else. I have seen corruption on
        one or more of these LSAs and don't want to wait
        until the removed LSAs could possilby be re-flooded.

        Mitchell Erblich
        ===============