Subject: Internet Draft : OSPF Refresh and Flooding in Stable Topologies

From: Erblichs <[email-masked]>
Date: Wed, 2 Apr 2003 12:30:47 -0800

Group,

        Sorry, just a few items to ponder :)

        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?

        Should it be stated that this knob is per interface?

        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?

        What is the implication of changing the knob twice within
        the standard 5 secs of re-originating the same LSA?

        Should a DNA LSA be removed upon loss of an adj due to
        the dead router interval expiring?

        **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....

        And lastly, should this document identify the procedure
        for removing its originated LSA before a orderly shutdown?

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

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 2 Apr 2003 13:13:49 -0800

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.

>         LSA will be reflooded by the originator? Should it be

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?

>         Should it be stated that this knob is per interface?

This is stated in section 5.

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

>         the standard 5 secs of re-originating the same LSA?

That would be implementation choice how to keep track of this.

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

>         that we would eventually see the LSA....

Any change in topology/configuration will result in LSA(s) being
flooded so this will clear up.

>         for removing its originated LSA before a orderly shutdown?

This is covered by the non-reachability rule.

>         Sr Software Engineer

Padma

---

From: Erblichs <[email-masked]>
Date: Wed, 2 Apr 2003 14:53:44 -0800

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

> >         Sorry, just a few items to ponder :)

        1)
> draft and having a router implementing DC somewhere in your topology
        2)
> That would be implementation choice how to keep track of this.
        3)
> originating an LSA with DNA bit set is lost that LSA should be maxaged.

        4)
> flooded so this will clear up.
        5)

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 3 Apr 2003 09:04:53 -0800

Mitchell Erblich,

>         adj hasn't also removed it. But not

What is this work ??

>         same LSAs in their database?????

No. The LSA contents are the same.

>          hello, then...redo the Init DB Sync)

I usually don't force anyone ;-)
???- Are you referring to the work above ?

>         But now you are making it apply to all
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.

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

>            the change? The orignator will not reflood
If the originator doesn't see a change that should cause a
change in contents in its LSA then there is a bug ;-)

>            follow? Shouldn't it explicitly be stated in

See response 3.

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

Padma

---

From: Erblichs <[email-masked]>
Date: Thu, 3 Apr 2003 10:25:44 -0800

Lets try  inlining this time..

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

> >         adj hasn't also removed it. But not

        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???
> ???- Are you referring to the work above ?

        Yes...
> 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.

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

> lingering LSAs will not be used in the SPF anyway. So, some

        Well Moy does the former in his book and I agree with
        his decision. See the shutdown function.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 3 Apr 2003 12:00:15 -0800

See below

>Lets try  inlining this time..

I think this draft is for a issue orthogonal to mine and let's not mix them.

>        time of reflush of the removed LSA, we then wait for the
This draft does not introduce any new issue from the rfc 1793. More
over, Section 5
mentions the forced periodic forced flooding. The parameter to be
configured to
whatever they want and hence still have a flooding of LSAs.

>                Yes, but shouldn't you possibly want to state
It can be stated.

>        his decision. See the shutdown function.

Let me put it like this .. my draft is about eliminating unneccessary
protocol
traffic .. and the maxaging on going out is unnecessary traffic.

Padma

---

From: Erblichs <[email-masked]>
Date: Thu, 3 Apr 2003 13:32:07 -0800

Padma Pillay_Esnault,

        I agree with your intention!

        However, in MY OPINION.

        1) Decrease the flooding interval to maybe
           50 minutes for LSAs without the DNA being
           set. Thus request that this archectural
           constant become a configurable parameter.

        2) Create a new capability that allows a minimal
           OOB request/ack for a single LSA over an adj
           with awareness of the LSA instance.

           - This would take care of a loss of synchronization
             due to checksum removal or some other loss.

           - Be able to have the request directed to the LSA
             originator when the below #3 header is identified.

        3) Suggest a new flooding low-overhead flood capability
           using LSA headers (ala IS-IS) that is defaulted to
           re-xmit every 30 minutes but can be set higher.

        4) Define a method for backward compatibility.

        Mitchell Erblich
        Sr Software Engineer
        ========================

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 3 Apr 2003 14:24:47 -0800

>           constant become a configurable parameter.

There was a passage in the draft that mentionned this explicitly as well as
its limitations. Our Chair asked me to remove it. You can bring it up to
Acee. ;-)

>             originator when the below #3 header is identified.

Not scalable in my opinion for a problem which is too rare and autosolved
by a periodic force refresh.

>           re-xmit every 30 minutes but can be set higher.

Problem that the LSAs will still die within 1hr. This draft gets more
flexibility.

>        4) Define a method for backward compatibility.

How is this draft not backward compatible ?

---

From: Erblichs <[email-masked]>
Date: Thu, 3 Apr 2003 15:42:33 -0800

Padma, :)

        Comments inline..

        Mitchell Erblich
        -------------

> its limitations. Our Chair asked me to remove it. You can bring it up

                I could guess what his issue was. That is another
                proposal to decreasing refresh and flooding and
                felt that the scope of your document didn't need
                to specify every possible way to decrease..

> by a periodic force refresh.

                I agree that a periodic forced refresh is simpler, but
                using updates pkts is a very high overhead method. The main
                problem is with periodic refresh without a request mechanism
                is that on avg you have to wait 1/2 of the refresh interval.
                This "periodic force refresh" could be set to days, weeks,
                months, years" and that would effectively remove asynchronous
                flooding requirement from OSPF!!!!!

                If you have a request mechanism, that avg wait time is
                decreased to 2x delay of the link plus time to process the
                request. LSA headers for flooding is really lightweight vs
                update pkts with a miminally changing or Stable environment.
                However, if the environment changes, a rush of LSA reqs
                could significantly increase the amount of traffic. Yes,
                I thought about this... But I was working with a Stable env
                assumption.

                My #2 and #3 compliment each other. The #2 can get instance
                information supplied by #3. Implimenting #2 without #3 or
                #3 without #2 wouldn't make sense.
> Problem that the LSAs will still die within 1hr. This draft gets more

                Yes, I am not removing the 1 hour timeframe. However, this SUGGESTION
                should significantly decrease the number of bytes be flooded,
which
                significantly decreases the amount of overhead in the flooding process
                for a STABLE TOPOLOGY. Yes, my suggestion still would require each
router
                to process the header packets and make LSA comparisons.

                With the new header information, my #2 suggestion would then be able
to
                take the instance and do a "Initial DBD Synchronization" like
comparison
                for a single LSA and follow up with a req / ack communication.

> How is this draft not backward compatible ?

                Noooo, yours draft is okay wrt this item.. What I was suggesting would
                 need a section for backward compatiblity.

> >> I think this draft is for a issue orthogonal to mine and let's not
> >> mix
> >> them.
> >>
> >> >> >> >         This document does not discuss the implications of
> >> >> >> > a
> >> >> >> > LSA
> >> >> >> >         Can the router that is removing the failed
> >> >> >> > checksum
> >> >> >> > LSA
> >> >> >> >         flood a earlier instance of the LSA? This hoping
> >> >> >> > that
> >> >> >> > the
> >> >> >> >         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
> >> >> >>   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
> >> >> >> >         Should a DNA LSA be removed upon loss of an adj
> >> >> >> > due
> >> >> >> > to
> >> >> >>   originating an LSA with DNA bit set is lost that LSA should
> >> >> >>  be
> >> >> >>   maxaged.
> >> >> >>
> >> >> >         4)
> >> >> >
> >> >> >> >         the DNA LSA, that a temporary routing loop or a
> >> >> >> > black
> >> >> >> > hole
> >> >> >> >         Now, after this temporary condition has cleared
> >> >> >> > will
> >> >> >> > some
> >> >> >> >         routers never get the LSA?  In the past we could
> >> >> >> > be
> >> >> >> > assured