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

Sriganesh Kini <sriganesh.kini@ericsson.com> Mon, 04 April 2011 21:34 UTC

Return-Path: <sriganeshkini@gmail.com>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E629D3A677C for <ospf@core3.amsl.com>; Mon, 4 Apr 2011 14:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.882
X-Spam-Level:
X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di5Edd4xq4e5 for <ospf@core3.amsl.com>; Mon, 4 Apr 2011 14:34:09 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id F36F23A66B4 for <ospf@ietf.org>; Mon, 4 Apr 2011 14:34:08 -0700 (PDT)
Received: by qwc23 with SMTP id 23so738234qwc.31 for <ospf@ietf.org>; Mon, 04 Apr 2011 14:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=aoI4mSUvVNuNQiJm5guRFdAewgedp+dB1BCHoVyLHnw=; b=XoERQLHxGRimQJwfTqcrLtwH6jdbDLnwoTvaP4nSQz3T6btmx9myisGgX07YrLM4jb t/AABoRMM4QvALp2Zo9Z5ALtpIsVs+e48YYcHsq6cnltXU+OyYxusWw1fzl+5N1Q64Zv G+rS54PVLrGvrSosYawlxTBHx+OV+DFv/TAY0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=id3wFBc8au3DHhLJqpQsKYD5xZnXfXWvS2jjdaA7LQSgqp1cAK/l6hC35U+BqACR93 n6zm1j96oh+eZPChGBwjcedAclYubon4+JLsTkMQvVoJCEM2OBkRYQvwMa2tGUSlvQ9J zSBn/9/+ElQtowW/D+ojUVduxNfD+SQcAo7u4=
Received: by 10.229.102.73 with SMTP id f9mr5969328qco.168.1301952951258; Mon, 04 Apr 2011 14:35:51 -0700 (PDT)
MIME-Version: 1.0
Sender: sriganeshkini@gmail.com
Received: by 10.229.231.143 with HTTP; Mon, 4 Apr 2011 14:35:21 -0700 (PDT)
In-Reply-To: <BANLkTinCQ=saW1OUt2i8PAfdUPE8_-G_fg@mail.gmail.com>
References: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> <BANLkTinCQ=saW1OUt2i8PAfdUPE8_-G_fg@mail.gmail.com>
From: Sriganesh Kini <sriganesh.kini@ericsson.com>
Date: Mon, 4 Apr 2011 14:35:21 -0700
X-Google-Sender-Auth: 1jm9mh0CUpbZP_zpb84zJWO6Ijo
Message-ID: <AANLkTimuWm3mXOdWw1qROcRuetSAQJiwPVeqkZA3D5ab@mail.gmail.com>
To: Vishwas Manral <vishwas.ietf@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: ospf@ietf.org
Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 21:34:11 -0000

Vishwas,

Your draft seems to be referring to the end-to-end delay of a packet
forwarded entirely by data-plane. So those results would be applicable
to the OSPF fast-notification. It would not be applicable to
end-to-end delay of OSPF LSA flooding since the LSAs are processed at
each hop by the control-plane.

Curtis,

The control-plane delays you haven't listed include sending LSUpdate
from data-plane to control-plane and its processing such as
authenticating, comparing against LSDB, sending LSAck (with potential
re-transmission), queueing for further flooding (including re-transmit
if timer expires), re-adding interface specific auth params etc. All
of these need to be done at each intermediate hop as the LSA gets
flooded and hence the delay is cumulative. These delays may not seem
like much but it does add to the overall delay in convergence. The SPF
by itself does not take that much time in modern CPUs but the download
of routes certainly increases with number of downloads. However,
modern forwarding architectures are such that in many failure
conditions many downloads are not needed. A single download can change
the nexthop of a large number of routes. In such conditions the
hop-by-hop control-plane flooding does not remain an insignificant
component of convergence. There will of course be networks where
geographic delay itself may be large enough to dwarf all other
numbers, but there are a lot of networks where that is not true.

We will be updating the draft to support the assertions.

Thanks

On Mon, Apr 4, 2011 at 1:36 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar <curtis@occnc.com> wrote:
> Hi Curtis,
>
>> Has anyone measured the per hop flooding delay that is incurred in
>> modern routers?
>
> From the few we have worked, it works from 10's of nanoseconds to microseconds.
>
> You may see some work on
> http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to
> actually add per device delay to make the solution generic, which is
> what we are trying to work on.
>
> Thanks,
> Vishwas
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>



-- 
- Sri