Re: [OSPF] Query regarding draft-ietf-ospf-ospfv3-graceful-restart-04.txt

Acee Lindem <acee@cisco.com> Thu, 30 November 2006 11:26 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpk3E-0002nS-7Y; Thu, 30 Nov 2006 06:26:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpk3C-0002ix-02 for ospf@ietf.org; Thu, 30 Nov 2006 06:25:58 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpk3A-0007eh-Lt for ospf@ietf.org; Thu, 30 Nov 2006 06:25:57 -0500
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 03:25:56 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAUBPuNp030346; Thu, 30 Nov 2006 03:25:56 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAUBPtdE012115; Thu, 30 Nov 2006 03:25:55 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 06:25:55 -0500
Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 06:25:54 -0500
Message-ID: <456EBFC2.5050700@cisco.com>
Date: Thu, 30 Nov 2006 06:25:54 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: satyapraveenkumar pasalapudi <pravin.adin@gmail.com>
Subject: Re: [OSPF] Query regarding draft-ietf-ospf-ospfv3-graceful-restart-04.txt
References: <f520df8b0611292225q3dbfd54aw14b1a3920cee1852@mail.gmail.com>
In-Reply-To: <f520df8b0611292225q3dbfd54aw14b1a3920cee1852@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Nov 2006 11:25:55.0043 (UTC) FILETIME=[4CC93330:01C71472]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1546; t=1164885956; x=1165749956; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Re=3A=20[OSPF]=20Query=20regarding=09draft-ietf-ospf-ospfv3-g raceful-restart-04.txt |Sender:=20; bh=P6U8WLhdXnioWfTXWrlqTt1UxO74RwryVVWhSKGY8NM=; b=VKby4RJ6G0NFW+yi/7MgNHODzK/oUH/EflcKEmZ7ZEJYbfRzzubSPWhjV+eUhzPWe2rEmO+B NQPFdU5uHepxCC09WBp/+641xtHCePQOt4O8QJSdA2ivzNemtktVKMVX;
Authentication-Results: sj-dkim-6; header.From=acee@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Praveen,

satyapraveenkumar pasalapudi wrote:
> Hi,
>
> In section
>
> *3.1  Preservation of LSA ID to Prefix Correspondence*
>
> *    In OSPFv2 there is a direct correspondence between type 3 and type 5
>    LSA IDs and the prefixes being advertised.  For OSPFv3, the LSA ID
>    for inter-area prefix LSAs and external LSAs is simply an unsigned 32
>    bit integer.  To avoid network churn during graceful restart, the
>    restarting router SHOULD preserve the LSA ID to prefix correspondence
>    across graceful restarts.*
>
> **
>
> My query is why is to maintain LS-ID prefix correspondence?
If we don't maintain the correspondence, it will cause churn since one 
or more
of the restarting router's self-originated LSAs containing prefixes will 
appear
to have changed. This, in turn, will result in unnecessary SPF 
calculations in
all the OSPFv3 routers  in the flooding domain of the changed LSAs.
Granted, this will be an incremental or partial SPF  for external, NSSA,
inter-area-prefix LSAs and inter-area-router LSAs. Furthermore,
if demand circuits (RFC 1793) or flooding reduction (RFC 4136) is deployed,
the changed LSAs will need to be flooded over these links.

Hope this helps,
Acee
>
> How it will cause network churn ?
>
>
>
> Rgds,
>
> Praveen.
>
> **
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>   

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf