IETF Logo Mail Archive

Re: fn-transport/ipfrr drafts

Alia Atlas <akatlas@gmail.com> Wed, 06 April 2011 00:58 UTC

Return-Path: <akatlas@gmail.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 9C3E23A68D2 for <rtgwg@core3.amsl.com>; Tue, 5 Apr 2011 17:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 kBPNaRiXWCRk for <rtgwg@core3.amsl.com>; Tue, 5 Apr 2011 17:58:37 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0FC913A682D for <rtgwg@ietf.org>; Tue, 5 Apr 2011 17:58:37 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1153707iwn.31 for <rtgwg@ietf.org>; Tue, 05 Apr 2011 18:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mjHhEQ4iwVOvMf4YAmUpxWPUXVD2R+Mg0kDZMFH2JR0=; b=UUUtHns5V5XPyjaFBp2axqjf/yvigKVDTyeYTNCd1aWeTtDgkXU+aLTRJlyiXtotZk 5qutOSe6wYwC9cIMoCQ7Be0K3TjHWlh+o/scQGYKHQ8QgZBewEiF1KrZZLTwNxJ/4LZc nhdMrLPXZ77t/o/u2bYpm/PcDSIprYZkrvx1Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vs+DRlaNDR7CAlUr2WGMwxdWOU5UsJpsEnyUS5ReFvsGPuJgQjmHdYVKm8w88HfbbB aAJmCx6FKlwC79nFv45EXY8Lv/yG3abn5o6+3KHxxEiDQHSTWGyul/gN14Nr5BvDbtdU OPkB4AbukK2Ch2j654nm1U4HE4LK8nHNbajAE=
MIME-Version: 1.0
Received: by 10.42.115.73 with SMTP id j9mr535524icq.117.1302051620158; Tue, 05 Apr 2011 18:00:20 -0700 (PDT)
Received: by 10.42.76.71 with HTTP; Tue, 5 Apr 2011 18:00:20 -0700 (PDT)
In-Reply-To: <201104052137.p35LbquQ061587@harbor.orleans.occnc.com>
References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com>
Date: Tue, 05 Apr 2011 21:00:20 -0400
Message-ID: <BANLkTimOkFh=Hm=g2KXBm7ysxqqBDsvHVw@mail.gmail.com>
Subject: Re: fn-transport/ipfrr drafts
From: Alia Atlas <akatlas@gmail.com>
To: curtis@occnc.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 06 Apr 2011 00:58:40 -0000

Curtis,

Andras is familiar with the problem IPFRR is trying to solve.

As I understand it, there are 3 separate questions:
   a) Is a multicast distribution mechanism that can report bad news
quickly & survive single failures useful?
   b) Is this useful for an IGP to speed network convergence?
   c) If one assumes very rapid ( speed of light)  delays for remote
failures, what pre-computation and FIB installation could be possible?

I have not heard requirements and rationale sufficient yet.
Security is also a concern - but the first questions are whether any
mechanism is  desirable.

Alia

2011/4/5 Curtis Villamizar <curtis@occnc.com>:
>
> 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
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

v2.23.0 | Report a Bug | By Email