Re: another appoach to OOB LSDB Resynchronization??

[Erblichs <[e-mail]>]

Vishwas,

        If he drops the hello then it
        still works, because..

        Is your DD being sent a one time
        or on a periodic basis?

        By the local router transiting back
        to 2-way, then I will be sending a DD
        packet if that neighbor should
        form a FULL adjacency.

        The local router will by its normal
        algorithms will determine whether a adj
        should be formed.

        The amount of code to implement this
        feature is less than 10 lines other
        than the CLI interface. And it works
        with less than 1 hour of work.

        The logic to stay as a DR or BDR is
        that it would assert its past declaration
        If a router booted up subsequently with
        a higher priority, a priority boost could
        be enabled.

        What interface or neighbor event specific
        allows you to just send a DD packet? What
        state would you be in to send your DD packet?
        How do you legally/ via the OSPF RFC get
        into this state? What happens if you are
        in the down state?


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




"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> ;-) Well all you require, in what i said, was a SeqNumberMismatch event
> generated at our end and every thing else proceeds as normal. You start
> sending DBD's and adjacencies form. Besides the SeqNumbermismatch would not
> occur during normal processing(unlike the 1-way event), only during error
> conditions(I guess !!!).
>
> In ur case how would you manage the case if the hello u sent without the
> neighbor was actually dropped. There are many many cases I can think of you
> would need to take care of(DR election etc).
>
> Anyways I feel signalling a bit is the best/cleanest approach to do it. That
> way we do not change anything during normal processing of the protocol, and
> only when we know for sure we want an OOB resynch we do as in the draft.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:[e-mail]]
> Sent: Friday, October 04, 2002 7:00 AM
> To: [e-mail]
> Subject: Re: another appoach to OOB LSDB Resynchronization??
>
> 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
>         ===============
>
> "Manral, Vishwas" wrote:
> >
> > 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:[e-mail]]
> > Sent: Tuesday, October 01, 2002 11:16 PM
> > To: [e-mail]
> > 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
> >         ==========================