Re: LSDB Overflow Limitation?
Charles Yi-tung Liang <Charles_Liang@ALPHANETWORKS.COM> Fri, 09 July 2004 05:40 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 BAA19717 for <ospf-archive@LISTS.IETF.ORG>; Fri, 9 Jul 2004 01:40:55 -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 <3.00E0CACA@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 1:40:55 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25132899 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 01:40:51 -0400
Received: from 210.202.42.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 01:40:50 -0400
Received: from hqmail1.alphanetworks.com (unverified) by sweeper2.alphanetworks.com (Content Technologies SMTPRS 4.3.10) with ESMTP id <T6ab0894bf1ac130317dac@sweeper2.alphanetworks.com> for <OSPF@peach.ease.lsoft.com>; Fri, 9 Jul 2004 13:38:41 +0800
Received: from CHARLESLIANG ([10.44.8.1]) by hqmail1.alphanetworks.com (Lotus Domino Release 5.0.12) with SMTP id 2004070913392267:11455 ; Fri, 9 Jul 2004 13:39:22 +0800
References: <OFBFA4F323.BBBA4EBD-ON48256ECB.006472BE-48256ECB.0064735C@alphanetworks.com> <087701c4652f$1fbc29f0$0202a8c0@aceeinspiron>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MIMETrack: Itemize by SMTP Server on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 01:39:22 PM, Serialize by Router on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 01:39:23 PM, Serialize complete at 07/09/2004 01:39:23 PM
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013B_01C465BA.71DFC7B0"
Message-ID: <013e01c46577$70b35110$01082c1e@CHARLESLIANG>
Date: Fri, 09 Jul 2004 13:41:31 +0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Charles Yi-tung Liang <Charles_Liang@ALPHANETWORKS.COM>
Organization: Alpha Networks Inc.
Subject: Re: LSDB Overflow Limitation?
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Acee/Mitchell, Thanks for the advice. So the goal of this feature should be "If someone detects overflow event, it should select (proper) self-originated LSAs to be prematured." Again, I'm curious about the limit count. If the statement above is what we want, why should we required the limit count to be consistent in all OSPF routers? (I know what the cases will be, such as the problem described in RFC. I'm asking about the possible result as I proposed. Is there any chance to meet this situation?) Charles ----- Original Message ----- From: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Sent: Friday, July 09, 2004 5:04 AM Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message is to be blocked by code: bknss61177) Charles, You can choose to implement RFC 1765 but you cannot advertise the fact that your router is in overflow state in a field in OSPF hello packets. First of all, there are no unused fields or option bits and even if there were we wouldn't want to allocate them for this purpose. There are free bits in the router LSA bits but personally I don't see a strong requirement to advertise entry or exit from overflow state. I don't agree with everything that has been stated in this mail thread but I do agree that RFC 1765 dates to a time when low-end routers had very limited memory. Again, you can choose to implement this RFC. However, I personally think a local knob specifying the upper limit on the number of external routes that you'll advertise is more useful. Thanks, Acee ----- Original Message ----- From: Charles Liang To: OSPF@PEACH.EASE.LSOFT.COM Sent: Thursday, July 08, 2004 2:17 PM Subject: Re: LSDB Overflow Limitation? 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
- LSDB Overflow Limitation? Charles Yi-tung Liang
- Re: LSDB Overflow Limitation? Erblichs
- Re: LSDB Overflow Limitation? Charles Liang
- Re: LSDB Overflow Limitation? Erblichs
- Re: LSDB Overflow Limitation? Acee Lindem
- Re: LSDB Overflow Limitation? Charles Yi-tung Liang
- Re: LSDB Overflow Limitation? Acee Lindem