RE: fn-transport/ipfrr drafts
John E Drake <jdrake@juniper.net> Wed, 06 April 2011 15:02 UTC
Return-Path: <jdrake@juniper.net>
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 15FBE28C11A for <rtgwg@core3.amsl.com>; Wed, 6 Apr 2011 08:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.374
X-Spam-Level:
X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 j9YscQ6E40eG for <rtgwg@core3.amsl.com>; Wed, 6 Apr 2011 08:02:50 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 95BF03A69BB for <rtgwg@ietf.org>; Wed, 6 Apr 2011 08:02:49 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTZyA/V6CCKp/7o/mQFMFuEbe+Fq21t6V@postini.com; Wed, 06 Apr 2011 08:04:33 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 6 Apr 2011 08:01:25 -0700
From: John E Drake <jdrake@juniper.net>
To: Alia Atlas <akatlas@gmail.com>, "curtis@occnc.com" <curtis@occnc.com>
Date: Wed, 06 Apr 2011 08:03:06 -0700
Subject: RE: fn-transport/ipfrr drafts
Thread-Topic: fn-transport/ipfrr drafts
Thread-Index: Acvz9cvSpu5eRwsIRUOsfuH8WNMJywAdEQjg
Message-ID: <5E893DB832F57341992548CDBB33316399F2CA7904@EMBX01-HQ.jnpr.net>
References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> <BANLkTimOkFh=Hm=g2KXBm7ysxqqBDsvHVw@mail.gmail.com>
In-Reply-To: <BANLkTimOkFh=Hm=g2KXBm7ysxqqBDsvHVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:02:51 -0000
Comments inline Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Alia Atlas > Sent: Tuesday, April 05, 2011 6:00 PM > To: curtis@occnc.com > Cc: rtgwg@ietf.org > Subject: Re: fn-transport/ipfrr drafts > > 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? JD: Is IGP flooding a significant contributor to network convergence and is a multicast distribution mechanism sufficiently faster to justify the control plane complexity associated with building and maintaining a multicast tree? Data plane support of multicast, even in hardware, involves packet replication and is seldom line-rate. The drafts' treatment of building and maintaining a multicast tree in a dynamic network is akin to 'magic happens'. > b) Is this useful for an IGP to speed network convergence? JD: See above. When we actually did this, nearly twenty years ago, it proved to be of dubious benefit. > c) If one assumes very rapid ( speed of light) delays for remote > failures, what pre-computation and FIB installation could be possible? JD: This is implementation specific and should be outside the scope of the discussion. > > I have not heard requirements and rationale sufficient yet. > Security is also a concern - but the first questions are whether any > mechanism is desirable. JD: You can probably guess what I think. > > 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 > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg
- Re: fn-transport/ipfrr drafts Curtis Villamizar
- Re: fn-transport/ipfrr drafts Curtis Villamizar
- fn-transport/ipfrr drafts Jeff Tantsura
- RE: fn-transport/ipfrr drafts András Császár
- Re: fn-transport/ipfrr drafts Curtis Villamizar
- Re: fn-transport/ipfrr drafts Alia Atlas
- Re: fn-transport/ipfrr drafts mike shand
- RE: fn-transport/ipfrr drafts András Császár
- RE: fn-transport/ipfrr drafts András Császár
- Re: fn-transport/ipfrr drafts Peter Psenak
- Re: fn-transport/ipfrr drafts Stewart Bryant
- RE: fn-transport/ipfrr drafts John E Drake
- RE: fn-transport/ipfrr drafts András Császár