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 RAA28264 for ; Thu, 8 Jul 2004 17:04:32 -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 <16.00E0BF6B@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 17:04:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25085354 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 17:04:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 17:04:31 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 24DDF6ACEC1 for ; Thu, 8 Jul 2004 14:04:30 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17858-05 for ; Thu, 8 Jul 2004 14:04:29 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.53]) by prattle.redback.com (Postfix) with SMTP id E34206ACEBF for ; Thu, 8 Jul 2004 14:04:28 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0874_01C4650D.9834E4C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <087701c4652f$1fbc29f0$0202a8c0@aceeinspiron> Date: Thu, 8 Jul 2004 17:04:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0874_01C4650D.9834E4C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Charles,=20 You can choose to implement RFC 1765 but you cannot advertise the fact that your router is in overflow state in a=20 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=20 allocate them for this purpose.=20 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.=20 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=20 think a local knob specifying the upper limit on the number of external routes that you'll advertise is more useful.=20 Thanks, Acee=20 ----- Original Message -----=20 From: Charles Liang=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 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=20 Erblichs Sent by: Mailing List 07/08/2004 09:07 AM MST Please respond to Mailing List To: OSPF@PEACH.EASE.LSOFT.COM cc:=20 bcc:=20 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 =3D=3D 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 ------=_NextPart_000_0874_01C4650D.9834E4C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Charles,
 
You can choose to implement RFC 1765 = but you=20 cannot
advertise the fact that your router is = in overflow=20 state in a
field in OSPF hello packets. First of all, there are no unused = fields
or option bits and even if there = were=20 we wouldn't want to
allocate them for this purpose. =
 
There are free bits=20 in the router LSA bits but personally
I don't see a strong requirement to = advertise entry=20 or
exit from overflow state.
 
I don't agree with everything that has = been stated=20 in this
mail thread but I do agree that RFC = 1765 dates to=20 a
time when low-end routers had very = limited memory.=20 Again, you
can choose to implement this RFC. = However, I=20 personally
think a local knob specifying = the upper limit=20 on the number
of external routes that you'll = advertise is more=20 useful.
 
Thanks,
Acee
----- Original Message -----
From:=20 Charles Liang =
Sent: Thursday, July 08, 2004 = 2:17=20 PM
Subject: Re: LSDB Overflow=20 Limitation?

Mitchell,

It sounds like we prefer to pre-allocate the resource,
rather = than=20 process the overflow conditions?!
I also belive that the number has = to be=20 matched with
the limit counts, and pre-allocating the = resource
should be=20 a pratical solution.

What I concerned is the exception? from RFC1765.
If we have to = implement=20 this feature, we'd like
to make sure the implementation works for=20 all
the possible cases.  Otherwise, shouldn't we prefer
to = announce=20 that my OSPF router will NEVER fall
into LSDB overflow state.

Therefore, I'm wondering that
(1) Is my realization about = RFC1765=20 correct?
(2) Will the problem that I described happen?
(3) Is = there any=20 side effect if I use a reserved
and unused field in = HELLO-Option?
(4) Is=20 it worth of implemeting RFC1765?

Charles

Erblichs=20 <erblichs@EARTHLINK.NET>
Sent by: = Mailing=20 List <OSPF@PEACH.EASE.LSOFT.COM>
07/08/2004 09:07=20 AM MST
Please respond to Mailing=20 List

To: OSPF@PEACH.EASE.LSOFT.COM
cc: =
bcc:
Subject: [ Spam Mail ]=20 Re: LSDB Overflow Limitation? (This message is to be blocked by code:=20 bknss61177)


Charles,

        The number really has to do = with
        the=20 number of non default AS-external
        LSAs.

        These are believed to represent = the
        maj of=20 LSAs in the LSDB.

        In my=20 experience, this only occurs
        with memory limited routers=20 and
        routers within the same area are
        normally set to the = same=20 values.

        Realize = that in=20 memory limited routers,
        you are pre-allocating enough = memory
        to=20 cover the limit and that memory will
        not be available for = other=20 functions.

        Mitchell = Erblich
        -----------------

> Charles Yi-tung Liang=20 wrote:
>
> Hi,
>
> Here below is my = understanding from=20 RFC1765
> to process lsdb overflow condition.
>
> = Goal: Make=20 every OSPF router to be awared of
> the overflow state, and thus = reduce=20 the number
> of lsdb.  That's why we required all the = OSPF
>=20 routers setup the same limited lsdb threshold.
>
> = Process: As=20 mentioned in RFC1765.
>
> Limitation?/Problem?:
> = Since the=20 new LSA update from someone triggers
> overflow state (when=20 currentLSACount =3D=3D limitedLSACount)
> via flooding, there is = chance that=20 certain OSPF router
> will miss such a critial event. =  Moreover,=20 the following
> premature actions may make someone else=20 believing
> there is not yet an overflow event.  Why don't = we just=20 set
> up a beacon bit to notify everyone?  For = example,
>=20 using a reserved filed in HELLO-Option to notify
> overflow.=20  Afterward, when all the neighbors acked
> with overflow=20 beacon-bit, reset (clear) such a bit.
>
> Could anyone = help=20 clearing my doubt?
>
> BTW, if the overflow process needs = to be=20 applied
> to Inter-AS LSAs (Area-Oriented), what kind of
> = LSA is=20 suggested to be prematured?  Can I leave
> RTRLink, = NetLink, and=20 ASSummary alone?
> Will OSPF WG include the overflow process = as
>=20 a part of OSPFv3?
>
> Thanks in = advance.
>
> = Charles

------=_NextPart_000_0874_01C4650D.9834E4C0--