Re: LSDB Overflow Limitation?

Charles Liang <Charles_Liang@ALPHANETWORKS.COM> Thu, 08 July 2004 18:22 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15344 for <ospf-archive@LISTS.IETF.ORG>; Thu, 8 Jul 2004 14:22:02 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00E0BB86@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 14:21:58 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25068381 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 14:21:54 -0400
Received: from 210.202.42.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 14:21:54 -0400
Received: from hqmail3.alphanetworks.com ([172.19.3.26]) by hqmail1.alphanetworks.com (Lotus Domino Release 5.0.12) with ESMTP id 2004070902212227:9983 ; Fri, 9 Jul 2004 02:21:22 +0800
MIME-Version: 1.0
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on HQMAIL3/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:17:12 AM, Itemize by SMTP Server on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:21:22 AM, Serialize by Router on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:21:24 AM, Serialize complete at 07/09/2004 02:21:24 AM
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="UTF-8"
Message-ID: <OFBFA4F323.BBBA4EBD-ON48256ECB.006472BE-48256ECB.0064735C@alphanetworks.com>
Date: Fri, 09 Jul 2004 02:17:11 +0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Charles Liang <Charles_Liang@ALPHANETWORKS.COM>
Subject: Re: LSDB Overflow Limitation?
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: base64

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 <erblichs@EARTHLINK.NET>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
07/08/2004 09:07 AM MST
Please respond to Mailing List

To: OSPF@PEACH.EASE.LSOFT.COM
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