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

Curtis Villamizar <> Tue, 05 April 2011 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAA3C28C13A for <>; Tue, 5 Apr 2011 13:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id plyp3KQvUv9p for <>; Tue, 5 Apr 2011 13:13:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C996728C12B for <>; Tue, 5 Apr 2011 13:13:29 -0700 (PDT)
Received: from ( []) by (8.13.6/8.13.6) with ESMTP id p35KF9RH060596; Tue, 5 Apr 2011 16:15:10 -0400 (EDT) (envelope-from
Message-Id: <>
To: "Bhatia, Manav (Manav)" <>
From: Curtis Villamizar <>
In-reply-to: Your message of "Tue, 05 Apr 2011 09:57:18 +0530." <>
Date: Tue, 05 Apr 2011 16:15:09 -0400
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 20:13:30 -0000

In message <>
"Bhatia, Manav (Manav)" writes:
> > 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

We have plenty of junk internet-drafts in IETF.  One or two less would
be better.  If it is not solving a real world problem then we should
get rid of it.  First we have to agree that there is a requirement.

draft-kini-ospf-fast-notification-01.txt calls for multicast, and
cites draft-lu-fast-notification-framework-00.txt for "transporting
the message encoding", but the latter makes no mention of multicast.

If multicast is used, a multicast routing protocol is needed.  A
multicast tree can have transient loops.  The last thing we need to
add to OSPF is a new control plane transient loop creation capability.
At least flooding is guarenteed to never loop.

When a fault occurs in a multicast tree, the tree must converge before
any other fault is reliably reported using multicast.  Multiple faults
are common.  Most are covered in protocols such as RSVP-TE that
support SRLG (but many are not even covered by SRLG).

This work is half thought out and it doesn't address a real problem so
I support telling the authors that it has no place in the OSPF WG.