Re: [OSPF] OSPF RS-bit in OSPF restart signalling

Liem Nguyen <lhnguyen@cisco.com> Tue, 26 September 2006 16:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSG9j-00021e-4P; Tue, 26 Sep 2006 12:51:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSG9g-00021J-1i for ospf@ietf.org; Tue, 26 Sep 2006 12:51:36 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSG9e-0000oj-Ks for ospf@ietf.org; Tue, 26 Sep 2006 12:51:36 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2006 09:51:34 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8QGpYVX026437; Tue, 26 Sep 2006 09:51:34 -0700
Received: from sjc-cde-016.cisco.com (sjc-cde-016.cisco.com [171.69.20.42]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8QGpX1E005570; Tue, 26 Sep 2006 09:51:33 -0700 (PDT)
Received: (lhnguyen@localhost) by sjc-cde-016.cisco.com (8.11.2/CISCO.WS.1.2) id k8QGpXr15573; Tue, 26 Sep 2006 09:51:33 -0700 (PDT)
Date: Tue, 26 Sep 2006 09:51:33 -0700
From: Liem Nguyen <lhnguyen@cisco.com>
To: sengottuvelan srirangan <sengottuvelan_s@yahoo.com>
Subject: Re: [OSPF] OSPF RS-bit in OSPF restart signalling
Message-ID: <20060926165133.GQ11712@sjc-cde-016.cisco.com>
References: <20060925102447.12309.qmail@web56512.mail.re3.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20060925102447.12309.qmail@web56512.mail.re3.yahoo.com>
DKIM-Signature: a=rsa-sha1; q=dns; l=1621; t=1159289494; x=1160153494; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lhnguyen@cisco.com; z=From:Liem=20Nguyen=20<lhnguyen@cisco.com> |Subject:Re=3A=20[OSPF]=20OSPF=20RS-bit=20in=20OSPF=20restart=20signalling; X=v=3Dcisco.com=3B=20h=3Dmp94sT8sR5nMReF9S0Srlefbt2k=3D; b=xIM0pxDKy4iPP68CSS8FSUWFwx5qlDfXepmc/2Sq8AVxU3YKRUPk4XVHG3SF8ScPZtsvzEFj IQsRUrggrMPRVmR8fBeTuII8vXCsZChI6yaV/3p09l4D/+SmxhLlNqW3;
Authentication-Results: sj-dkim-2.cisco.com; header.From=lhnguyen@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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

Sengottuvelan,

On Mon, Sep 25, 2006 at 03:24:47AM -0700, sengottuvelan srirangan wrote:
> Hi All,
>    
>   I have doubt on OSPF RS-bit in OSPF restart signalling.  The RS-bit must not be set in Hello packets longer than RouterDeadInterval seconds.
> 
>   Suppose i have two links one is configured with 20 sec as dead interval and another as 80 sec.
>    
>   1. Suppose a neighbor is reached to Full in 20sec configured link, what happens to RS-bit on the 80sec link?

The RS-bit is set and cleared on a per-interface basis.

>   2. Suppose there is no neighbor in 20sec link  and there is a neighbor in 80sec link.
>   3. Suppose 20 and 80 links have neighbors
>    
>   In these cases, what is the expected behavior of a restarting router?

It depends on if the neighbor receives/accepts the RS-bit Hellos or not;
the mechanism works in conjuction with the corresponding neighbor's
'ResyncTimeout' timer (2.2).  The neighbor could reset the adjacency with 
the restarting router, for which the restarting need to recognize and react.

It's implementation specific as far as how you want to control/limit the
the restart.
Technically, the restart and oob-resync
(http://tools.ietf.org/wg/ospf/draft-nguyen-ospf-oob-resync-05.txt)
can occur on a per-interface basis.  If restart fails for one interface,
you can choose to terminate restart totally, or you can continue restart
on other interfaces because theoretically, transit flows on other interfaces
could be uninterrupted. Depending on the paranoid level, you may just
chose to terminate restart (also see 2.3) as a whole.

Liem

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