Re: LSDB Overflow Limitation?

[Acee Lindem <[e-mail]>]

Charles, 

What I said was that I thought a configurable local
limit on the number of external routes that may be exported into
OSPF was simpler and more useful than RFC 1765.  You'll have to
make your own feature/implementation decisions based on your
target market and its associated requirements. 

Thanks,
Acee 
  ----- Original Message ----- 
  From: Charles Yi-tung Liang 
  To: [e-mail] 
  Sent: Friday, July 09, 2004 1:41 AM
  Subject: Re: LSDB Overflow Limitation?


  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: [e-mail] 
    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: [e-mail] 
      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 <[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