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

Acee Lindem <acee@REDBACK.COM> Fri, 31 January 2003 17:20 UTC

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 MAA12651 for <ospf-archive@LISTS.IETF.ORG>; Fri, 31 Jan 2003 12:20:11 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.008C2DE3@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 12:23:44 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 590070 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 12:23:44 -0500
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 12:23:43 -0500
Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 60DECBD247 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 31 Jan 2003 09:23:42 -0800 (PST)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3E37DE0C.8090206@redback.com> <067801c2c910$ba7fe9c0$81c802c0@alok>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3E3AB0C9.2070708@redback.com>
Date: Fri, 31 Jan 2003 12:22:17 -0500
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Alok,

Let me attempt to address your points inline below.

alok wrote:
> 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?

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.

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

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

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

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

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

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.


>
> is my interpretation correct?
>
> -rgds
> Alok
>
>
>
> ----- Original Message -----
> From: Acee Lindem <acee@REDBACK.COM>
> To: <OSPF@DISCUSS.MICROSOFT.COM>
> Sent: Wednesday, January 29, 2003 7:28 PM
> Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt
>
>
>
>>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
>>
>
>


--
Acee