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

Anton Smirnov <asmirnov@cisco.com> Mon, 11 April 2011 22:33 UTC

Return-Path: <asmirnov@cisco.com>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B5E0E06D4 for <ospf@ietfc.amsl.com>; Mon, 11 Apr 2011 15:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPO0WQeMPdwJ for <ospf@ietfc.amsl.com>; Mon, 11 Apr 2011 15:33:34 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id D480BE06D1 for <ospf@ietf.org>; Mon, 11 Apr 2011 15:33:20 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3BKsiCN022823 for <ospf@ietf.org>; Mon, 11 Apr 2011 22:54:44 +0200 (CEST)
Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3BKsf6G008403 for <ospf@ietf.org>; Mon, 11 Apr 2011 22:54:42 +0200 (CEST)
Message-ID: <4DA36A91.7070305@cisco.com>
Date: Mon, 11 Apr 2011 22:54:41 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8
MIME-Version: 1.0
To: ospf@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [OSPF] draft-kini-ospf-fast-notification-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 11 Apr 2011 22:33:36 -0000

    Hi all,
    even though I put OSPF-FN draft in the subject it is the framework 
approach FN-FRWK which draws more questions. At the very first line it 
reads:

> This document describes an architectural work that competes with the
> IP Fast Re-Route (IPFRR) solution

Lets compare speed of traffic restoration between the two. So, 
traditional OSPF convergence time consists of the sum of:

1. Failure detection
2. LSA origination
3. Per-hop flooding
4. SPF (delay and calculation itself)
5. RIB/FIB/hardware update

3, 4 and 5 all can be significant depending on network size, number of 
routes etc.

FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation 
FRR should be by order of magnitude as fast as 1.

FN addresses only 3. It doesn't address 4 and 5. As I wrote above in 
many networks they are at least as significant as 3.

So, by the speed of convergence FN doesn't look to come anywhere close 
to FRR.


    Now, lets look at FN from another perspective. Router announcing 
failure doesn't benefit from FN. Its immediate neighbors do not benefit 
from FN either - 1 hop traditional flooding should be as fast as 1 hop 
FN flooding. It is only distant routers who benefit from the FN - and 
the farther is router from the failure the bigger is gain.
    On the other hand, if there exists path alternative to the failed 
one then _typically_ it is not too far (in terms of hops) from the 
failing one. I.e. from point of view of router which is 15 hops away 
from the point of failure it is less likely that routes will change. 
BTW, ordered FIB approach builds on concept that 'old' routes on remote 
routers do not cause traffic blackholing or loops.

    The big problem with FN approach is that routers remote from the 
point of failure benefit most - but at the same time their convergence 
is the least important for end-to-end traffic restoration.
    The worst case network for FN is fully meshed area. Since each 
router is 1 hop away from every other one FN will give no benefits.
    The best case network for FN is an area consisting of one big ring. 
In this case alternative path is on diametrically opposite end of the 
network and convergence of remote routers is crucial.

    So yeah, FN will help remote routers to converge faster. But how 
much this will improve end-to-end traffic restoration in real networks? 
I suspect not much. Some degree of meshiness in network topology is the 
norm.

    FN is an interesting proposal but it is very far from being 
convincing. Pitching FN against FRR is a mistake.

-- 
Anton