Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt

From: Acee Lindem <[email-masked]>
Date: Wed, 29 Jan 2003 08:58:36 -0500

This is the start of a Working Group last call for
draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart.
All comments must be sent to the OSPF list by Friday,
February 8th, 2003.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt

My previous list posting on this WG last call was lost or
filtering. My apologies if this is a duplicate.

Thanks,
Acee & Rohit
--
Acee

---

From: alok <[email-masked]>
Date: Fri, 31 Jan 2003 15:38:21 +0530

Hi,

there is something which I would appreciate if someone could clarify

1. what is "restarting" and what is "after restarting" state? essentially my
concern being:

page 2

     (2)   The restarting router runs its OSPF routing calculations, as
           specified in Section 16 of [1]. This is necessary to
           return any OSPF virtual links to operation. However, the
           restarting router does *not* install OSPF routes into the
           system's forwarding table(s), instead relying on the
           forwarding entries that it had installed prior to the
           restart.

what does point 2 mean?

again mentioned on 2.3 point 3, it says after it has "exited restart state"
the routes will be put in the FT.

what defines hitless restart time is the "grace period" which means "the
router wont originate LSAs till LSRefreshtimer" :
In order to avoid
        the restarting router's LSAs from aging out, the grace period
        should not exceed LSRefreshTime (1800 second)

.....which anyways is the default operation if there is no topology change.
(i hope I am right here)

doing it this way implies that if there is a topology change elsewhere when
the router is down, we would wait till the "old LSAs the router was
orginating" become stale......to update the FT.

so why "wait" for that time at all before updating the FT

would making the simple test be "grace period is over as soon as OSPF
reestablishes adjacencies and time passed since the begininning of restart
is less than MinLSinterval"..hence start populating the FT with the new
entries....

is my interpretation correct?

-rgds
Alok

---

From: Acee Lindem <[email-masked]>
Date: Fri, 31 Jan 2003 12:22:17 -0500

Hi Alok,

Let me attempt to address your points inline below.

>            forwarding entries that it had installed prior to the

Conceptually, you have to have an OSPF route table that is independent
of the forwarding table(s). Virtual links will be marked UP as soon as there
is a transit area route to the virtual link's endpoint ABR. A restarting
router cannot update the forwarding table until it exits graceful restart.

>         should not exceed LSRefreshTime (1800 second)

The grace interval expiring is only one of many reasons to exit graceful
restart.

> orginating" become stale......to update the FT.

Nope - if we receive a copy of our LSA that is inconsistent with the
pre-restart copy we will exit graceful restart immediately. See 2.2 (2).

> is less than MinLSinterval"..hence start populating the FT with the new

An OSPF router will exit graceful restart prior to the grace interval if
it establishes all its prior adjacencies. See 2.2 (1). There are also
some implementation dependent wait condition relating to route redistribution
but those are beyond the scope of this document.

--
Acee

---

From: alok <[email-masked]>
Date: Fri, 31 Jan 2003 22:59:52 +0530

so As MR deepak said
ccing him

no neighbour router suppout for this, (even one) nomore owrking of draft?

ciao
alok

----- Original Message -----
From: Acee Lindem <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 31, 2003 10:52 PM
Subject: Re: Working Group Last Call for
draft-ietf-ospf-hitless-restart-05.txt

---

From: Acee Lindem <[email-masked]>
Date: Fri, 31 Jan 2003 12:54:45 -0500

> no neighbour router suppout for this, (even one) nomore owrking of draft?

Almost - non-support from any neighbor that was fully adjacent prior to
restart will result in the restarting router aborting graceful restart when
it detects a discrepancy in the router's intra-area LSAs (i.e., type 1 or
2).

Publishing this draft as an RFC will go along ways towards promoting
universal support.

>>>1. what is "restarting" and what is "after restarting" state?
>>
> essentially my
>
>>>concern being:
>>>
>>>page 2
>>>
>>of the forwarding table(s). Virtual links will be marked UP as soon as
>
> there
>
>>>again mentioned on 2.3 point 3, it says after it has "exited restart
>>
> state"
>
>>>.....which anyways is the default operation if there is no topology
>>
> change.
>
>>>(i hope I am right here)
>>>
>>>doing it this way implies that if there is a topology change elsewhere
>>
> when
>
>>>reestablishes adjacencies and time passed since the begininning of
>>
> restart
>
>>some implementation dependent wait condition relating to route
>
> redistribution
>
>>>Subject: Working Group Last Call for
>>

--
Acee

---

From: alok <[email-masked]>
Date: Fri, 31 Jan 2003 23:46:34 +0530

> it detects a discrepancy in the router's intra-area LSAs (i.e., type 1 or
 and that means : as the draft says....the "non helper" neighbour screws the
guy who supports the "helper"...why does life sound better on a black board?

so lets dump those "routers"?? who dont rely supporting this?...........??
uh oh>?
one screw up

can one reboot in :routerdeadinterval"......and why not?

my next RFC says .....make it to 60seconds?? possible?

yes..........if u "big" guys pass it ;o)