From: Erblichs (erblichsEARTHLINK.NET)
Date: Wed Apr 02 2003 - 16:53:44 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Padma Pillay-Esnault,

        Let me re-phrase the first question.

        1) One of the most common methods that a
        stable OSPF router does is the periodic
        verification of the checksums of
        LSAs within its database.

        Upon checksum verifcation failure and
        removal, (router just removes the bad
        LSA and marks the memory location as
        suspect) then non-aynchronous flooding
        will not resubmit the removed LSA....

        Note: With the draft that deals with
        the later re-Initial Database Synchronization
        work, we can get back the LSA if the
        adj hasn't also removed it. But not
        yet..

        So, you then break the assumption that
        all routers within an area must have the
        same LSAs in their database?????

        You just forced us to
        take doown the interface
        if we have a DNA LSA on a non-DC configured
        interface and we fail a checksum? Right???

        (Actually, identify the adj that submitted
         us the LSA, and remove him from the next
         hello, then...redo the Init DB Sync)

        *** Yes, This problem was not reported to
        me early on dealing with demand-circuits!
        I don't know why other people dont't see
        this. Maybe people have perfect memory or
        they just don't run the checksuming algorithm.
        The current solution is to restart the
        DC interface where the LSDB originated to
        restart the Initial Database Synchronization.

        Else, we wait for the asynchronous re-submit of
        the LSA. It depends on the time that we last saw
        the LSA instance.

        But now you are making it apply to all
        interfaces / adjs ...

        2) Oops, section 5 does specify interfaces or
           globaly.

        3) Let me state this one.. Reachability in the
           Demand Circuit is 1 hr, etc. Shouldn't your
           document state that reachability is based
           on Dead Router Interval? You reference a
           doc and take some things from it and leave
           this type of item "explicitly unstated".

        4) Are you stating reflooding by the LSA orignator?
           What happens if the originator doesn't see
           the change? The orignator will not reflood
           the LSA...

` 5) The non-reachability rule for Demand-Circuit
           specifies 1 hr, but for normal routers specify
           dead-router interval? Which one should we
           follow? Shouldn't it explicitly be stated in
           the document?

           Remember, I stated an orderly shutdown. Why
           don't we reflood with MAX-AGE, to remove
           un-necessary LSAs? This is analgous to RIP's
           poisson reverse something...

        Mitchell Erblich
        Sr Software Engineer
        ---------------------------

Padma Pillay-Esnault wrote:
>
> Mitchell,
>
> First let me state that this feature can only operate if
> all the routers have an understanding on how to handle DNA
> LSA per rfc 1793.
>
> >
> > Group,
> >
> > Sorry, just a few items to ponder :)
> >

        1)
> > This document does not discuss the implications of a LSA
> > being corrupted (LSA checksum failed) and then being
> > discarded.
> >
> > Should we not do checksums on DNA LSAs?
> >
> > Can the router that is removing the failed checksum LSA
> > flood a earlier instance of the LSA? This hoping that the
> > LSA will be reflooded by the originator? Should it be
> > stated here?
>
> I am not sure I understand your question.
> How does handling this case differ between a router implementing this
> draft and having a router implementing DC somewhere in your topology
> and emitting DNA LSAs?
>
        2)
> >
> > Should it be stated that this knob is per interface?
>
> This is stated in section 5.
>
> >
> > Should it be stated what happens if the knob is first to
> > have normal flooding, then reduced flooding or vice versa,
> > OR more simply stated the requirement to reflush the LSA
> > that are having their DNA bit changed?
> >
> Do you mean to state that turning off the feature should cause all
> the LSAs to be reflooded with the DNA bit clear ? This seemed obvious
> to me. But any ways, on the first refresh of the LSA on the originating
> router this will cause the LSA to be flooded with the new sequence
> number and DNA bit clear.
>
> > What is the implication of changing the knob twice within
> > the standard 5 secs of re-originating the same LSA?
>
> That would be implementation choice how to keep track of this.
>
        3)
> >
> > Should a DNA LSA be removed upon loss of an adj due to
> > the dead router interval expiring?
>
> This is part of rfc 1793 that when reachability to the router
> originating an LSA with DNA bit set is lost that LSA should be maxaged.
>

        4)
> >
> > **What is the implication that during the initial flooding of
> > the DNA LSA, that a temporary routing loop or a black hole
> > existed? This could even be due to mis-router configuration?
> > Now, after this temporary condition has cleared will some
> > routers never get the LSA? In the past we could be assured
> > that we would eventually see the LSA....
>
> Any change in topology/configuration will result in LSA(s) being
> flooded so this will clear up.
>
        5)
> >
> > And lastly, should this document identify the procedure
> > for removing its originated LSA before a orderly shutdown?
>
> This is covered by the non-reachability rule.
>
> >
> >
> > Mitchell Erblich
> > Sr Software Engineer
> > -----------------------------------
> >
>
> Padma

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]