From: Padma Pillay-Esnault (padmaJUNIPER.NET)
Date: Tue Apr 08 2003 - 18:56:49 CDT

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

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

> 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.

> 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
>

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