Re: [GROW] [Idr] Potential route flap with bgp-diverse-path

Robert Raszuk <raszuk@cisco.com> Sun, 27 March 2011 20:52 UTC

Return-Path: <raszuk@cisco.com>
X-Original-To: grow@core3.amsl.com
Delivered-To: grow@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D824F28C152; Sun, 27 Mar 2011 13:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 QF4khX53yEEL; Sun, 27 Mar 2011 13:52:20 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D046A28C119; Sun, 27 Mar 2011 13:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1302; q=dns/txt; s=iport; t=1301259238; x=1302468838; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UT9IEFkK8sSYwpNX84f3gdKQewLGluACuJ6DdmpRHmY=; b=MzGbmwl19N98o1ca8fydArVUrUXvstfMdQ2sjI5rmrVRwxwtl+rWXqnZ SgT2H4/3RkF5mPJLgdWZxU4EobzJzEcWCgV1bnMLQVK8VkwlwsNc48Jmv wb17uAIxWhoJtuIA2Jp0GjK6WJgnAhBlQAj5mP+X1zqTsZAmHOCVisfYU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIejj02rRDoH/2dsb2JhbAClUXeIa5xEgm8OAZd3hWkEjHeDVA
X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="671405972"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Mar 2011 20:53:58 +0000
Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RKrudg025765; Sun, 27 Mar 2011 20:53:57 GMT
Message-ID: <4D8FA3E4.304@cisco.com>
Date: Sun, 27 Mar 2011 22:53:56 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> <4D8FA268.3000705@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] [Idr] Potential route flap with bgp-diverse-path
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2011 20:52:22 -0000

 > In the previous email, you said the exact opposite:
 > "Yes it would advertise overall best if backup is missing."

That is true but this is not applicable to the case here.

Here RRs as you have indicated would have P1, P2 and P3 and when P1 goes 
down there is backup on both RRs.

Thx,
R.


>>> If every RR plane must send a path, then the clients
>>> will have N paths for every destination, even if there
>>> is only one path.
>>
>> Nope that is not a requirement as discussed in the previous email.
>
> In the previous email, you said the exact opposite:
> "Yes it would advertise overall best if backup is missing."
>
> You require that to stop the flap.
>
>>
>>   >  Please make a recommendation on how many RR planes
>>   >  are optimal.
>>
>> For all applications of today I see 2 as sufficient and optimal.
>>
>> Thx,
>> R.
>>
>>
>>>
>>> Given N RR planes,
>>> that means clients will need N times the BGP memory
>>> and N times the BGP processing power for destinations
>>> with only one path.
>>>
>>> Please make a recommendation on how many RR planes
>>> are optimal.
>>>
>>> --
>>> Jakob Heitz.
>>
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>