[OSPF] draft-kini-ospf-fast-notification-01

Curtis Villamizar <curtis@occnc.com> Mon, 04 April 2011 20:31 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id ED0A928C0E5 for <ospf@core3.amsl.com>; Mon, 4 Apr 2011 13:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-2.413, BAYES_00=-2.599, GB_SUMOF=5]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id HF6WPA3npbYg for <ospf@core3.amsl.com>; Mon, 4 Apr 2011 13:31:32 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com []) by core3.amsl.com (Postfix) with ESMTP id 27C5428C0E2 for <ospf@ietf.org>; Mon, 4 Apr 2011 13:31:31 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com []) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p34KXDqG024310; Mon, 4 Apr 2011 16:33:13 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com>
To: ospf@ietf.org
From: Curtis Villamizar <curtis@occnc.com>
Date: Mon, 04 Apr 2011 16:33:13 -0400
Sender: curtis@occnc.com
Subject: [OSPF] draft-kini-ospf-fast-notification-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2011 20:31:36 -0000

Has anyone measured the per hop flooding delay that is incurred in
modern routers?

If this is small compared to geographic delay (speed of light delay)
then there is no need for this work.  Many routers forward packets
directly to a line card CPU and coordinate flooding among line card
CPU processors, a bit like flooding inside the chassis.  Worst case
for a high priority process is about two interrupt times.  Interrupt
times on a modern CPU is about 100 usec.  If there are a lot of LSA
being flooded, then many LSA can be picked up in one system call if
driver code is written to allow this.  Even where this goes to the
CPU, modern code is smart enough to have the SPF run in a different
thread or process, so as not to hold up any further flooding.  There
was a presentation in NANOG on this topic about 5 years ago or more
but I don't have a pointer to the URL at the moment.

The assertion in the abstract that "The delay due to the involvement
of the control-plane adversely affects OSPF convergence" is not
supported in the draft and certainly not in my experience.  The SPF
time is typically long compared to the sum of per hop flooding delays
due to hitting a CPU.