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

"Bhatia, Manav (Manav)" <> Mon, 04 April 2011 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0B5F3A6823 for <>; Mon, 4 Apr 2011 16:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.704
X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UkSqyqSFmTR7 for <>; Mon, 4 Apr 2011 16:57:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C01063A6821 for <>; Mon, 4 Apr 2011 16:57:35 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p34NxBf7003466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 18:59:13 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p34NxA4R010936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 05:29:10 +0530
Received: from ([]) by ([]) with mapi; Tue, 5 Apr 2011 05:29:10 +0530
From: "Bhatia, Manav (Manav)" <>
To: Sriganesh Kini <>, Vishwas Manral <>
Date: Tue, 5 Apr 2011 05:29:16 +0530
Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01
Thread-Index: AcvzEEm7tDC0xH81R+aioTQK78xmlQAEfPjw
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
Cc: "" <>
Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Apr 2011 23:57:37 -0000

> 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

You will have more delays even before this. The LSAs need to be picked up from the HW to the CPU and based on your queue scheduling algorithm there could be some delays there. Typically if its strict scheduling then you would drain all the BFDs, EFMs, LACPs, OSPF HELLOs, etc before you get to the LSUpdates. Once you have drained all such packets from the HW they will only be processed once your OSPF task gets a CPU slice. It will then take some time in processing the LSUpdates as it may have Hellos queued up ahead (based on the architecture). Similarly, at the egress there could again be some delays. If there is a central task that's responsible for sending out the packets then it could also be maintaining priority queues and LSUpdates will certainly not get into the highest. While I understand that all these delays are very small, they do start adding up as the LSAs travel hop-by-hop. It also starts getting significant as your router starts becoming busy and the processes have to contend for the CPU cycles. If the router software is not entirely lockless then you would also see processes stalled because some other task has acquired a lock that they're waiting on. So, forwarding them in the HW seems like a good idea provided we can make it work without making the solution too convoluted and complex.

Cheers, Manav

> 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