From: Erblichs (erblichsEARTHLINK.NET)
Date: Thu Apr 03 2003 - 12:25:44 CST

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

Lets try inlining this time..

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

Padma Pillay-Esnault wrote:
>
> Mitchell Erblich,
>
> >
> > 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..
>
> What is this work ??

        OSPF Out-of-band LSDB resynchronization
        by Alex Zinn and Abhay Roy
        Cisco, Feb 2001

        And truly, I don't know what is happening with it???
>
> >
> > So, you then break the assumption that
> > all routers within an area must have the
> > same LSAs in their database?????
>
> No. The LSA contents are the same.
>
> >
> > 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)
>
> I usually don't force anyone ;-)
> ???- Are you referring to the work above ?

        Yes...
>
> >
> >
> > *** 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 ...
> >
> Let assume that what you say happens in a regular topology -
> an LSA gets corrupted and discarded then the SPF should run and
> this route and others including it in their SPF calculation
> should be discarded. Hence we will lose routes for at the maximum
> 30 minutes. I have not heard anyone complain about such a problem
> in normal. I believe that it is very rare if it indeeds happens.
>

        Maybe implimentations are skipping the periodic checksum.

        The 30 minutes is assuming that asynchronous flooding will
        occur started at the originator. Your draft changes from
        30 minutes to whenever the originator refloods the LSA if
        ever. So, a route can now be lost for an undeterminate
        amount of time, if you don't do anything. I don't think that
        is good.

        BTW, If our current dyanmic SPF wait interval (see Cisco's
        SPF Throttling Paper on their web site) which approximates
        this paper, (max of 600,000 ms) is less than the expected
        time of reflush of the removed LSA, we then wait for the
        reflood.

> >
> > 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".
> >
> Remember that this is *not* DC. We are not setting DC bit
> in the hellos or in the DBD packets. So it is Dead Interval.
>
                Yes, but shouldn't you possibly want to state
                this in the RFC?

> > 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...
> >
> If the originator doesn't see a change that should cause a
> change in contents in its LSA then there is a bug ;-)
>
> >
> > ` 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?
> >
>
> See response 3.
>
> > 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...
> >
>
> This is an implementation decision. When you lose your adjacency,
> the LSA from the originating router will not be used in the spf
> anyway. Flooding MAXAGE LSA can be very expensive while the
> lingering LSAs will not be used in the SPF anyway. So, some
> believe it is useless.

        Well Moy does the former in his book and I agree with
        his decision. See the shutdown function.
>
> Padma
>
> > 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 ]