Re: fn-transport/ipfrr drafts

Curtis Villamizar <curtis@occnc.com> Tue, 05 April 2011 21:36 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: rtgwg@core3.amsl.com
Delivered-To: rtgwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B3A3A67E1 for <rtgwg@core3.amsl.com>; Tue, 5 Apr 2011 14:36:13 -0700 (PDT)
X-Quarantine-ID: <Vqp6D5kBIcBG>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E1 hex): To: Andr\341s Cs\341sz\341r <Andr[...]
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level:
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 Vqp6D5kBIcBG for <rtgwg@core3.amsl.com>; Tue, 5 Apr 2011 14:36:12 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 2959B3A67C1 for <rtgwg@ietf.org>; Tue, 5 Apr 2011 14:36:12 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p35LbquQ061587; Tue, 5 Apr 2011 17:37:52 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201104052137.p35LbquQ061587@harbor.orleans.occnc.com>
To: Andr�s Cs�sz�r <Andras.Csaszar@ericsson.com>
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: fn-transport/ipfrr drafts
In-reply-to: Your message of "Tue, 05 Apr 2011 15:12:29 +0200." <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se>
Date: Tue, 05 Apr 2011 17:37:52 -0400
Sender: curtis@occnc.com
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 21:36:13 -0000

In message <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se>
András Császár writes:
>  
> Dear All,
>  
> Note that fn-transport already is at version 01. Links to the docs:
>  
> http://tools.ietf.org/html/draft-lu-fn-transport-01
> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00
>  
> We'd really appreciate comments and suggestions. 
>  
> András


Same comment as on the OSPF mailing list.  This is attacking a
non-problem.

Flooding time is not a problem on modern implementations, unless the
implementation is badly designed or badly coded.

IPFRR is intended to eliminate the need for an SPF and route
download and the need to contact any other router in any way to get an
initial repair done.  That is a different problem.

Curtis


> > -----Original Message-----
> > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] 
> > On Behalf Of Jeff Tantsura
> > Sent: 2011. március 29. 14:58
> > To: rtgwg@ietf.org
> > Subject: fn-transport/ipfrr drafts
> > 
> > Hi rtgwg,
> > 
> > The authors would like to solicit comments from the workgroup.
> > 
> > draft-lu-fn-transport-00
> > draft-csaszar-ipfrr-fn-00
> > 
> > Thank you in advance!
> > 
> > Regards,
> > Jeff