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

"Bhatia, Manav (Manav)" <> Tue, 05 April 2011 04:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 847993A6878 for <>; Mon, 4 Apr 2011 21:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.703
X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PtXzaFWZLIMd for <>; Mon, 4 Apr 2011 21:25:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D3CD83A6877 for <>; Mon, 4 Apr 2011 21:25:42 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p354RLZR013855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 23:27:24 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p354RKXq005367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 09:57:20 +0530
Received: from ([]) by ([]) with mapi; Tue, 5 Apr 2011 09:57:20 +0530
From: "Bhatia, Manav (Manav)" <>
To: "" <>
Date: Tue, 5 Apr 2011 09:57:18 +0530
Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01
Thread-Index: AcvzOMWKeSZDVLdCRrGNCXiliv07mAADWi0g
Message-ID: <>
References: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <> <>
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: Tue, 05 Apr 2011 04:25:43 -0000

> There is no question that you *can* design and/or code things badly.
> There was work done by Packet Designs and Qwest a while back and
> reported in NANOG.  After this work, a major router vendor's
> implementation was optimized and a lot of delays were removed.  A big
> mistake they were making is SPF and route install first and then
> reflood.  It is better to get the word out that there is a problem.

I believe RFC 2328 is quite clear that LSAs should be flooded before "recalculating the routing table structure", so I am quite surprised that there were implementations that were doing otherwise. Thus I don't think anybody on this list seriously believes that this is an issue that folks are trying to solve. I believe the idea is quite simple - Flooding a changed LSA in HW (data plane) is faster than doing it in SW (not matter how optimized the latter is) or your control plane.

Lets at least look at the proposed solution and see if its worth considering. Who knows the discussion might lead us to something better that we may want to use. 

Also note that I am not the author or in any way related to the draft! :) 

Cheers, Manav