From: Erblichs (erblichsEARTHLINK.NET)
Date: Mon Apr 14 2003 - 15:14:36 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Acee Lindem,

        Inline...

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

Acee Lindem wrote:
>
> Erblichs wrote:
> > Group,
> >
> > First of all I would want to apologize for continuing
> > this discussion thread!
> >
> > I realize that some implimentions may exist based on
> > this draft and what I am suggesting, may effect changes
> > to them.
>
> Mitchell,
>
> No apologies necessary for discussion of the draft. However, please make
> every attempt to read and understand it before suggesting substantive
> changes.
>
> >
> > In my past emails I have implicitly ignored the section
> > 5 within this draft of "Unplanned outages". I will now
> > explicitly state why I have ignored its suggested method.
> >
> > Why?
> > * " must originate grace-LSAs *after* its control
> > software resumes operation", we now lose our DR or
> > BDR status, if it had existed.
>
> The restarting router will succeed DR status if it was previously DR. See
> section 2 number 3. Also note section 5 for applicablility to unplanned
> restarts. Changes in BDR should have no effect on adjacencies or LSA
> contents.

        I am really lost here..

        IFF we are unplanned, won't the normal deadrouterinterval
        timeouts take down the adjs? Remember the "*after*"
        section.

        If the restarting router was the DR or a BDR, a new election
        will occur to re-elect a new DR and/or BDR, and new adjs
        will form. Now, the premise of minimizing topological changes
        as a reason to keep the pre-shutdown DR / BDR combo, will
        no longer apply.

        Even if we declare ourselves the DR after re-start, there
        is only a chance that the reason why we were initially
        elected still applies, thus we may no longer have the
        highest priority of eligible routers.

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

>
> >
> > - This forces a SPF recomputation..
> > - This can forces many full adj reformations.
> > - Removes the helper relationship with
> > respect to the restarting router
> > (monitoring, continues to (its) advertise its
> > LSAs, etc) NIT: remove the first "its".
> > - etc..
> >
> > Thus this section invalidates many of the reasons
> > for the draft's existance.
> >
> > * If the draft's unplanned outages did not have these
> > negative effects and more, then anytime > 1 hr
> > graceful restart is planned, then this would be a
> > solid alternative. I just cannot see anyone
> > forwarding any pkts accross a non-adj, so even if
> > your forwarding table contents are sanitized, it
> > will be ignored.
> >
> > So, from may past information dump, the only true side effect
> > other than mentioned in the draft (clean flag for the forwarding
> > table should remove the table sanity issue) are the issues of the
> > reflooding bandwidth of early grace-LSAs, just in case the router
> > has an unplanned restart. And the extra work that is placed on
> > helper routers to "monitor" the network for topology changes,
> > and its other assigned helper duties.
> >
> > Thus, I believe that I have more than sufficiently identified
> > a graceful restart mechanism that removes the AFTER requirement
> > and allows the planned graceful restart method to be used in a
> > unplanned way. Plus, I agree that a knob/CLI command should be
> > used to enable or disable this type of feature.
> >
> > Mitchell Erblich
> > Sr Software Engineer
> > ----------------------
> >
> > Acee Lindem wrote:
> >
> >>Erblichs wrote:
> >>
> >>>Acee, et al,
> >>>
> >>> I didn't really want to continue this thread
> >>> but I feel, I should restate some items here. :)
> >>>
> >>>
> >>>
> >>>>As Padma stated, the draft supports unscheduled restarts (there
> >>>>are multiple interoperable implementations). Your proposal to
> >>>>announce graceful restart in advance
> >>>
> >>>
> >>>
> >>> I don't see how one can send out grace-LSAs and possibly be
> >>> able to retransmit a grace-LSA OTHER than in advance,
> >>> AND still support unscheduled graceful restarts!!!
> >>
> >>Mitchell,
> >>
> >>In the case of unscheduled restart you may send the grace LSA a couple
> >>times but you don't want for an acknowledge (you don't necessarily know your
> >>neighbors since you are learning the state from the networks).
> >>
> >>I suggest you read or review section 5 of the draft. It covers all of your
> >>concerns below.
> >>
> >>
> >>> You must do it in advance, else it is scheduled..
> >>>
> >>> My definition of unscheduled is that some event occurs and
> >>> the non-forwarding portion of the router is DOWN... No,
> >>> time for an sys admin to do anything...
> >>>
> >>> The ONLY possible way is to have trap level code call
> >>> the xmit grace-LSA code section. However, no time to
> >>> see if acks have been rec'vd and no time for a 5 sec
> >>> rexmit....
> >>>
> >>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your
> >>> guys opinion????
> >>>
> >>> On the assumption that if the router fails and
> >>> still abides by the condition that it is still
> >>> forwarding as if it was still up.., then
> >>>
> >>> As long as there isn't any topologoy changes
> >>> as stated within your document, that is one
> >>> reason to allow for a graceful restart, I don't
> >>> see the blackhole..
> >>>
> >>> If the topology changes then it would invalidate
> >>> my graceful restart, as it would also invalidate
> >>> the graceful restart specified in the draft.
> >>>
> >>> The only deltas that I was asking for was:
> >>> - the issue of sending out a minimal grace-LSA at
> >>> adj timeframe,
> >>> - being able to minimally update our grace-LSA as
> >>> topology changes,
> >>> - or we decide that we want to withdraw our grace-LSA
> >>> via MAXAGE,
> >>>
> >>> As of this time, I have not read in your document,
> >>> EXPLICITLY whether
> >>> - you suggest to ONLY send out the grace-LSA when you
> >>> have planned to do a restart (scheduled),
> >>> - how to withdraw the grace-LSAs from accepted helpers
> >>> when one proto-helper (to be helper), will not ack
> >>> your LSA,
> >>> - etc..
> >>>
> >>>
> >>> Mitchell Erblich
> >>> Sr Software Engineer
> >>> ============================
> >>>
> >>>
> >>>
> >>>
> >>>Acee Lindem wrote:
> >>>
> >>>
> >>>>Erblichs wrote:
> >>>>
> >>>>
> >>>>>Padma,
> >>>>>
> >>>>>
> >>>>> These are my last comments!!
> >>>>>
> >>>>> Also inline...
> >>>>>
> >>>>> Why doesn't the draft RFC authors want to
> >>>>> allow non-scheduled restarts in this
> >>>>> draft?
> >>>>
> >>>>Michell,
> >>>>
> >>>>As Padma stated, the draft supports unscheduled restarts (there
> >>>>are multiple interoperable implementations). Your proposal to
> >>>>announce graceful restart in advance will unnecessarily delay
> >>>>the detection of a black hole if the restarting router is really dead
> >>>>or was abruptly decommissioned. The current draft doesn't suffer
> >>>
> >>>>from this flaw.
> >>>
> >>>>
> >>>>> Is there something wrong with the idea
> >>>>> of un-scheduled restarts?
> >>>>>
> >>>>> Why restrict it to only scheduled
> >>>>> restarts???
> >>>>>
> >>>>> Why require
> >>>>> the grace-LSAs to be reflooded every
> >>>>> 30 minutes to 1 hr???
> >>>>>
> >>>>> Why not send the grace-LSAs without
> >>>>> the Type=1, Length=4 grace period field??
> >>>>> It will be determined by the helpers
> >>>>> anyway.
> >>>>>
> >>>>> The sentance is.
> >>>>>
> >>>>> "The number of seconds that the router's
> >>>>> neighbors should continue to advertise the
> >>>>> router as fully adjacent"....
> >>>>>
> >>>>> Thus, without the word "MUST", implimentations
> >>>>> will probably follow their own rules. Thus, the
> >>>>> grace period field really isn't needed and just
> >>>>> consumes bandwidth!!!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Mitchell Erblich
> >>>>> ===================
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Padma Pillay-Esnault wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Mitchell,
> >>>>>>
> >>>>>>I'll try to address your comments
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Acee Lindem,
> >>>>>>>
> >>>>>>> Since,, you skipped the inline re-comments, I will assume
> >>>>>>> that at least you read them.. :)
> >>>>>>>
> >>>>>>> I think I have expressed as best as I could (I am not
> >>>>>>> a tech writer) how I feel that this draft should evolve.
> >>>>>>>
> >>>>>>> So in summary...
> >>>>>>>
> >>>>>>>` 0) Remove the length (seconds) field from the grace-LSA.
> >>>>>>>
> >>>>>>
> >>>>>>This is using the TLV format .. so you want to keep the length
> >>>>>
> >>>>>
> >>>>> Of course, Type, Length, Value... Fine. Reword..
> >>>>> Remove
> >>>>> the Grace-Period field of (Type =1, Length = 4).
> >>>>> Why transmit the field value?????
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> 1) Transmit DNA grace-LSAs at adj creation time.
> >>>>>>>
> >>>>>>
> >>>>>>This is not very useful. Today unless you have DNA lsa you cannot
> >>>>>>expect to be requesting a grace period of over one hour -- as
> >>>>>>all the LSA in the other routers database will expire at the
> >>>>>>most in 1hr.
> >>>>>>So if you decide to send a grace LSA it would be the most recent one
> >>>>>>that you built and hence if it has time to expire then the previous
> >>>>>>would already be gone.
> >>>>>
> >>>>>
> >>>>> Think ahead of tomarrow, not today...
> >>>>> How should this work in the utopian word? If the graceful
> >>>>> restart is a good idea, then it NOT should be used for ALL
> >>>>> possible restarts??
> >>>>>
> >>>>> Why not restrict the amount of flooding with THESE types
> >>>>> of LSAs if this draft becomes a standard RFC??
> >>>>>
> >>>>> What happens if I send the grace-LSAs at adj formation
> >>>>> time and then reflood them every 55 minutes?? This
> >>>>> removes the lightweight mechanism of the draft, but
> >>>>> still gets me unscheduled restart functionality? Maybe
> >>>>> i will just do that.. BTW, and also do unscheduled
> >>>>> restarts with my BGP protocol once it becomes a
> >>>>> standard.
> >>>>>
> >>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if
> >>>>> I follow your logic, then why do I ask for 1 hr? Should
> >>>>> my implimentation in the helper not ack the grace-LSA if
> >>>>> the specified grace-period is over 1 hr from the restarting
> >>>>> router? This is unspecified behavior!!!
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> 2) Let the helpers determine amount of time that
> >>>>>>> they will function as a helper. Suggest a minimum
> >>>>>>> of 1 hr time.
> >>>>>>>
> >>>>>>
> >>>>>>This is a matter of policy .. even if the helper decides that
> >>>>>>he is not going to help for the whole period .. as he is not
> >>>>>>going to signal it to the restarting router .. I do not see
> >>>>>>the use of doing so.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents
> >>>>>>> have changed.
> >>>>>>>
> >>>>>>
> >>>>>>See my response in 1.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> 4) If the restart router expects to be down for a period
> >>>>>>> longer than X, then retransmit the Grace-LSAs as
> >>>>>>> MAXage LSAs.
> >>>>>>>
> >>>>>>
> >>>>>>I do not see the benefit or I am missing your point
> >>>>>>
> >>>>>>Padma
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> This would minimize bandwidth requirements and allow a
> >>>>>>> restarting router to have either scheduled or unscheduled
> >>>>>>> restarts.
> >>>>>>>
> >>>>>>> I don't know what else to add, except if you adopt one or
> >>>>>>> more of these suggestions, then please add my name to your
> >>>>>>> comment list. :)
> >>>>>>>
> >>>>>>> Mitchell Erblich
> >>>>>>> Sr Software Engineer
> >>>>>>> ============================
> >>>>>>>
> >>>>>>>
> >>>>>>>Acee Lindem wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Erblichs wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Acee Lindem,
> >>>>>>>>>
> >>>>>>>>> Sometimes my logic is a little obtuse..
> >>>>>>>>>
> >>>>>>>>> Most of it is inline...
> >>>>>>>>>
> >>>>>>>>> I will first throw two new questions to you!!!!
> >>>>>>>>>
> >>>>>>>>> 1) Why don't you send out the Grace LSA at full
> >>>>>>>>> adj timeframe. It would take effect after
> >>>>>>>>> RouterDeadinterval has expired?
> >>>>>>>>
> >>>>>>>>How do you know, apriori, that the OSPF instance is
> >>>>>>>>restarting and not completely dead?
> >>>>>>>
> >>>>>>> Why do you care? As long as the topology isn't changing
> >>>>>>> then everything is ok.
> >>>>>>>
> >>>>>>> Wwhy not minimize the effects of unnecessary SPF computations?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> This would also take care of unscheduled restarts
> >>>>>>>>> and allow you to do an unscheduled graceful
> >>>>>>>>> restart!!!!
> >>>>>>>>>
> >>>>>>>>> You could also send them as DNA LSAs.. See inline.
> >>>>>>>>>
> >>>>>>>>> The only new twist is that if you then schedule
> >>>>>>>>> a restart, you may want to be able to cancel your
> >>>>>>>>> previous request or update the LSAs over time.
> >>>>>>>>> But if you conisder a stable topology, then why
> >>>>>>>>> NOT??
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2) A) 2.1 3rd, paragraph..
> >>>>>>>>> "Their age field set to 0,"
> >>>>>>>>> Why can't you send DNA grace-LSAs????
> >>>>>>>>
> >>>>>>>>You wouldn't gain anything since the grace interval cannot
> >>>>>>>>exceed the LSA refresh time.
> >>>>>>>>
> >>>>>>>
> >>>>>>> So, first why do you need to specify the grace-LSA
> >>>>>>> timeframe. Let it be implicitly known to be 1 hr!
> >>>>>>>
> >>>>>>> With DNA grace-LSAs, we
> >>>>>>> don't need to reflood them. If I sent them out
> >>>>>>> at adj creation time and the topology isn't
> >>>>>>> changing, then I don't need to consume
> >>>>>>> resources and keep on re-flooding them..
> >>>>>>>
> >>>>>>> Thus, they can last multiple hours or longer..
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> B) 2.1, 4th paragraph.
> >>>>>>>>>
> >>>>>>>>> "it should retransmit... until
> >>>>>>>>> they are acknowledged". If you can't retransmit the
> >>>>>>>>> same LSA until 5 secs have passed, if a router
> >>>>>>>>> was congested, you may want to resubmit the grace-LSA
> >>>>>>>>> with a longer length timeframe to your helpers. I am
> >>>>>>>>> assuming just bump your instance. Correct?
> >>>>>>>>
> >>>>>>>>There are implementations that back off LSA retransmissions and the
> >>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion
> >>>>>>>>Avoidance" draft recommends this. However, this is not standard
> >>>>>>>>OSPF flooding as described in RFC2328 and it is an independent
> >>>>>>>>issue.
> >>>>>>>>
> >>>>>>>
> >>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are
> >>>>>>> ack'ed, you can't continue successfully with a graceful-restart.
> >>>>>>>
> >>>>>>> This delay consumes time that you specified in your grace-LSA. Yea,
> >>>>>>> again, I don't know why you need to specify the amount of time!!
> >>>>>>> The timeframe that the helpers will help you can be set independently
> >>>>>>> and your spec doesn't allow them to communicate the amount of time
> >>>>>>> that they will keeep around a grace-LSA.
> >>>>>>>
> >>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually
> >>>>>>> reduces the amount of time before the grace-LSA expires.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> Mitchell
> >>>>>>>>> ================
> >>>>>>>>>Acee Lindem wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Mitchell,
> >>>>>>>>>>
> >>>>>>>>>>See answers below.
> >>>>>>>>>>
> >>>>>>>>>>Erblichs wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Group,
> >>>>>>>>>>>
> >>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all
> >>>>>>>>>>> the LSAs were from DC specified NBRs with DNA
> >>>>>>>>>>> LSAs should the LS RefreshTime still be followed?
> >>>>>>>>>>
> >>>>>>>>>>LSA Refresh isn't relevant since the restarting router will
> >>>>>>>>>>reestablish adjacencies.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime
> >>>>>>>>> in your draft at the end of the 1st paragraph in section
> >>>>>>>>> 2.1?
> >>>>>>>>>
> >>>>>>>>> In my scenario, there would be no reason not to let the
> >>>>>>>>> value approach or exceed 3600 secs (1 hr).
> >>>>>>>>>
> >>>>>>>>> variation on a theme? Why not let the max value of your
> >>>>>>>>> grace-LSA length field allow the helper determine what
> >>>>>>>>> is the max that he will support?
> >>>>>>>>> -- what happens if you specify a value that is
> >>>>>>>>> greater than what the helper supports?
> >>>>>>>>> Ans A: The helper sees it as an invalid request
> >>>>>>>>> and throws away the whole request,
> >>>>>>>>>
> >>>>>>>>> OR
> >>>>>>>>> Ans B: The helper determines what the length he
> >>>>>>>>> will support?
> >>>>>>>>>
> >>>>>>>>> If it is B, then why have the length field. Just let
> >>>>>>>>> the helper decide how long to support the request?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number
> >>>>>>>>>>> (3) "The grace period expires".
> >>>>>>>>>>>
> >>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished
> >>>>>>>>>>> all its adjacencies" criteria is not met?
> >>>>>>>>>>
> >>>>>>>>>>The restarting router will exit graceful restart anyway.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Why? If you still have a non-changing topology, why
> >>>>>>>>> limit the value to what you had said to the helpers?
> >>>>>>>>>
> >>>>>>>>> So, what if you asked for x time and it took you
> >>>>>>>>> x + y time?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> Or are you stating that the specified "grace period" was
> >>>>>>>>>>> to short to perform what was required?
> >>>>>>>>>>
> >>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart
> >>>>>>>>>>cannot be completed successfully.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful
> >>>>>>>>>>> restarting router id", force it to exit?
> >>>>>>>>>>
> >>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello
> >>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse
> >>>>>>>>>>this with other graceful restart proposals.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I see that my question with the hello was answered in the
> >>>>>>>>> 2. (3) "an hello packet is received"..
> >>>>>>>>>
> >>>>>>>>> I am confused. One router may list you as the DR and another
> >>>>>>>>> may not? If one is a helper, then why would it take the adj
> >>>>>>>>> down if all the crieria were met?
> >>>>>>>>>
> >>>>>>>>> I thought that helpers
> >>>>>>>>> MUST send hellos as if you (graceful restarting router) were
> >>>>>>>>> still there!!
> >>>>>>>>> "an Hello packet is received from a neighbor listing the
> >>>>>>>>> router as the Designated Router".
> >>>>>>>>>
> >>>>>>>>> If it did keep anouncing you in the hellos (you weren't
> >>>>>>>>> the DR) and lets say that the DR went down. Could you
> >>>>>>>>> then be elected as the DR while you were still rebooting?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful
> >>>>>>>>>>> restarting router id as the earlier DR or BDR, cause
> >>>>>>>>>>> it to exit, if it was a DR / BDR?
> >>>>>>>>>>
> >>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause
> >>>>>>>>>>the restarting router to exist graceful restart prematurely.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we
> >>>>>>>>>>> determine our existing nbrs and place their router ids
> >>>>>>>>>>> in a hello?
> >>>>>>>>>>
> >>>>>>>>>>This isn't changed for graceful restart.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I thought that you could save past nbr-ids in NVRAM
> >>>>>>>>> and then compare to existing hellos...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the
> >>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't
> >>>>>>>>>>> that inform others that we are back and to cancel
> >>>>>>>>>>> their helper graceful nbr timer?
> >>>>>>>>>>>
> >>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart".
> >>>>>>>>>>>
> >>>>>>>>>>> 7) Shouldn't the sending hellos be performed that
> >>>>>>>>>>> identify full adj be a criteria here?
> >>>>>>>>>>
> >>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer
> >>>>>>>>>>mechanism for determining the graceful restart can be exited.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 8) I am unsure whether you are specifying the
> >>>>>>>>>>> storage of part of restarting router's LSDB into
> >>>>>>>>>>> non-volatile memory. If so, then upon retrieval,
> >>>>>>>>>>> shouldn't some elements of the LSDB be aged
> >>>>>>>>>>> by the amount that the actual amount of time
> >>>>>>>>>>> the LSAs were in NV memory?
> >>>>>>>>>>
> >>>>>>>>>>There is no mention of storing LSAs in non-volatile storage.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM
> >>>>>>>>> or some other type of storage media..
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> Mitchell Erblich
> >>>>>>>>>>> ==================================
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>--
> >>>>>>>>>>Acee
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>--
> >>>>>>>>Acee
> >>>>>>>
> >>>>--
> >>>>Acee
> >>>
> >>>
> >>--
> >>Acee
> >
> >
>
> --
> Acee

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]