IETF Logo Mail Archive

Re: [Idr] draft-uttaro-idr-bgp-persistence-00

"UTTARO, JAMES" <ju1738@att.com> Wed, 02 November 2011 17:53 UTC

Return-Path: <ju1738@att.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC511E814C for <idr@ietfa.amsl.com>; Wed, 2 Nov 2011 10:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.043
X-Spam-Level:
X-Spam-Status: No, score=-106.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKFBsLg+0XGw for <idr@ietfa.amsl.com>; Wed, 2 Nov 2011 10:53:33 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id CD7A411E8147 for <idr@ietf.org>; Wed, 2 Nov 2011 10:53:32 -0700 (PDT)
X-Env-Sender: ju1738@att.com
X-Msg-Ref: server-12.tower-119.messagelabs.com!1320256409!47794857!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6413 invoked from network); 2 Nov 2011 17:53:30 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Nov 2011 17:53:30 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2HruMU030113; Wed, 2 Nov 2011 13:53:57 -0400
Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2HrsDs030068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Nov 2011 13:53:54 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 13:53:26 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "'bruno.decraene@orange.com'" <bruno.decraene@orange.com>, "robert@raszuk.net" <robert@raszuk.net>
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00
Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMQAAMOCAlZntKQA=
Date: Wed, 02 Nov 2011 17:53:26 +0000
Message-ID: <B17A6910EEDD1F45980687268941550FA22608@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><B17A6910EEDD1F45980687268941550FA20750@MISOUT7MSGUSR9I.ITServices.sbc.com> <4EA84254.9000400@raszuk.net> <FE8F6A65A433A744964C65B6EDFDC24002951E94@ftrdmel0.rd.francetelecom.fr> <4EB14BDD.7040802@raszuk.net> <FE8F6A65A433A744964C65B6EDFDC24002951F8C@ftrdmel0.rd.francetelecom.fr> <4EB17893.1060706@raszuk.net> <FE8F6A65A433A744964C65B6EDFDC24002951FD2@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <FE8F6A65A433A744964C65B6EDFDC24002951FD2@ftrdmel0.rd.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.4.51]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2011 17:53:37 -0000

I believe that the what is being missed in this discussion is impact... Yes Dual RR failures are rare but when they happen it is analogous to an asteroid killer, you know, front page NYT etc.. So although it is a low frequency event the impact is beyond the pale.. Without getting into specifics I know this has happened. It needs to be defended against in a way that does not rely on probabilities of different RRs from different vendors on different platforms.. All of that may lessen the chance ( maybe ) but it comes with a huge testing/certification/inter-operability etc... challenge and does not guarantee protection. 

Thanks,
	Jim Uttaro

-----Original Message-----
From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] 
Sent: Wednesday, November 02, 2011 1:22 PM
To: robert@raszuk.net
Cc: idr@ietf.org; UTTARO, JAMES
Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00

>> Sure. But given the small number of RR boxes, and the high
requirements
>> on these boxes, it's harder to justify a two or three vendor
sourcing.
>
>I would think just the very opposite. Small number of RRs and their
high
>requirements IMHO fully justify more then one vendor sourcing.

Somehow we disagree on this. 
Regarding the small number of RR, if you need 10 RR, it's hard to go to
the buying, testing, integration and ops teams asking for a new vendor
for 5 only boxes.
Regarding dual sourcing, to keep redundancy, you would need to restrict
yourself to the smaller intersection of features and performance. This
can be limiting.


>Of course fun starts where it is hard to find such diverse RRs with all
>required feature sets.

My point. Both features and scale.

> Those concerned about such issues are looking
>actively in solving the problem fundamentally at it's roots and not
>cover it with yet another curtain.

Dual sourcing helps but does not guaranty that both RR will never fail.
You said it yourself. So this does not solve the fundamental problem.

However, again, given the low probability of double failure, it's harder
to justify work on this.

>Cheers,
>R.

v2.23.0 | Report a Bug | By Email