Re: another appoach to OOB LSDB Resynchronization??

["Manral, Vishwas" <[e-mail]>]

Hi Mitchell,

If u generate the SeqNumberMismatch event at ur end DB description packet is
sent from ur end as usual and retransmissions etc happen as usual, you dont
require any special mechanism for that. Also the event only occurs in case
of error, so it could be interpreted to mean an OOB synch.

If something can be done without sending hellos as you said(even if hellos
were dropped it would still work), then why send it(wrong hello) at all. ;-)

Anyway I guess the discussion isn't of much value to others, so let us stop
it here. However if u have doubts you can mail me in private.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[e-mail]]
Sent: Saturday, October 05, 2002 3:09 AM
To: [e-mail]
Subject: Re: another appoach to OOB LSDB Resynchronization??


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