Re: LSDB Overflow Limitation?

[Erblichs <[e-mail]>]

Charles,

        First 1765 is experimental. However, it is fairly
        simple to impliment and I think most vendors
        have implimented it.

        Using unused reserved bits SHOULD ONLY be done
        in controlled research environments with no
        connections outside of this environment.

        Your goal is wrong IMO. If overflow state is
        reached, selectively originate certain LSAs.
        Else, allow some routers to orginate those
        LSAs and others not to so LSDB convergence
        is achieved. Default routing will achieve
        the same means, although less efficent. If
        the problem persists admins should partition
        the area or reconfigure parts of the area
        as stubs or get more memory for the routers, or..

        An option is not necessary when the LSDB
        overflow event is achieved. Purging and limiting
        should be sufficent to achieve convergence.

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



Charles Liang wrote:
>
> Mitchell,
>
> It sounds like we prefer to pre-allocate the resource,
> rather than process the overflow conditions?!
> I also belive that the number has to be matched with
> the limit counts, and pre-allocating the resource
> should be a pratical solution.
>
> What I concerned is the exception? from RFC1765.
> If we have to implement this feature, we'd like
> to make sure the implementation works for all
> the possible cases.  Otherwise, shouldn't we prefer
> to announce that my OSPF router will NEVER fall
> into LSDB overflow state.
>
> Therefore, I'm wondering that
> (1) Is my realization about RFC1765 correct?
> (2) Will the problem that I described happen?
> (3) Is there any side effect if I use a reserved
> and unused field in HELLO-Option?
> (4) Is it worth of implemeting RFC1765?
>
> Charles
>
> Erblichs <[e-mail]>
> Sent by: Mailing List <[e-mail]>
> 07/08/2004 09:07 AM MST
> Please respond to Mailing List
>
> To: [e-mail]
> cc:
> bcc:
> Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message is
> to be blocked by code: bknss61177)
>
> Charles,
>
>                The number really has to do with
>                the number of non default AS-external
>                LSAs.
>
>                These are believed to represent the
>                maj of LSAs in the LSDB.
>
>                In my experience, this only occurs
>                with memory limited routers and
>                routers within the same area are
>                normally set to the same values.
>
>                Realize that in memory limited routers,
>                you are pre-allocating enough memory
>                to cover the limit and that memory will
>                not be available for other functions.
>
>                Mitchell Erblich
>                -----------------
>
> > Charles Yi-tung Liang wrote:
> >
> > Hi,
> >
> > Here below is my understanding from RFC1765
> > to process lsdb overflow condition.
> >
> > Goal: Make every OSPF router to be awared of
> > the overflow state, and thus reduce the number
> > of lsdb.  That's why we required all the OSPF
> > routers setup the same limited lsdb threshold.
> >
> > Process: As mentioned in RFC1765.
> >
> > Limitation?/Problem?:
> > Since the new LSA update from someone triggers
> > overflow state (when currentLSACount == limitedLSACount)
> > via flooding, there is chance that certain OSPF router
> > will miss such a critial event.  Moreover, the following
> > premature actions may make someone else believing
> > there is not yet an overflow event.  Why don't we just set
> > up a beacon bit to notify everyone?  For example,
> > using a reserved filed in HELLO-Option to notify
> > overflow.  Afterward, when all the neighbors acked
> > with overflow beacon-bit, reset (clear) such a bit.
> >
> > Could anyone help clearing my doubt?
> >
> > BTW, if the overflow process needs to be applied
> > to Inter-AS LSAs (Area-Oriented), what kind of
> > LSA is suggested to be prematured?  Can I leave
> > RTRLink, NetLink, and ASSummary alone?
> > Will OSPF WG include the overflow process as
> > a part of OSPFv3?
> >
> > Thanks in advance.
> >
> > Charles