Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection

Robert Raszuk <raszuk@cisco.com> Sun, 27 March 2011 23:00 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 DC01028C17D; Sun, 27 Mar 2011 16:00:18 -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 n-a5qVvgI+1u; Sun, 27 Mar 2011 16:00:17 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8BE7828C0E2; Sun, 27 Mar 2011 16:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4663; q=dns/txt; s=iport; t=1301266914; x=1302476514; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fuAlxvxiwy8VMMWAmNw+3JAaE8UNdWARIR7txQVW934=; b=APgPU2Pb2VmykSXZfQvDAJpNNHF31b1CfhvIUPFOLoH53HQyThAtGegT 8f3k2u7VN5IXA/2kNFGFsX/5Mrt7XZ8OCpiYn6W9voOLbttoGHz+56DNJ 1XyJH+lxxVokw0QyrXV+xXZo8Yotu5g8DfasHjwzrFAXrz87mVYHU3Wu6 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucAAELBj02rRDoG/2dsb2JhbACYE40+d4hrnCyCbw4Bl3aFaQSMd4NU
X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="325472702"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 23:01:54 +0000
Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RN1rKt021150; Sun, 27 Mar 2011 23:01:53 GMT
Message-ID: <4D8FC1E0.6000809@cisco.com>
Date: Mon, 28 Mar 2011 01:01:52 +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: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@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] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection
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 23:00:19 -0000

Hi,

 > C1 will choose second best and C2 will choose best.

I am sorry but each client will choose the best and backup path among 
the paths it receives. And this selection are normal IBGP best path 
selection. We are not really defining an AS wide path ordering in this 
work. All we are doing is distributing more paths to clients so they 
could use it for backup or load-balancing purposes.

Are you saying that what RR considers as backup may be chosen as best by 
the client ?

That seems to me perfectly fine. Client has no need to choose the same 
path as the RR. Because the second path would be a backup path on the 
client. With hop by hop IP lookup this is the reality today. With 
tunnels of some sort this becomes completely transparent, but this is 
different story and diverse-path does not require tunneling.

Even today RRs may choose different best path when they are full meshed 
and advertise different to each client. Then client is at his own 
freedom to choose order of paths as he likes.

Moreover the same behaviour would be in add-paths. Among advertised 
paths there is no ordering and clients can choose whichever order it 
consider's correct.

Cheers,
R.

> Suppose 2 clusters.
> Cluster 1 has 2 diverse path speakers, RR11 and RR12
> and client C1.
> Cluster 2 has 2 diverse path speakers, RR21 and RR22.
> and client C2.
>
> Suppose BGP Identifiers:
> RR11 = 11  advertises best
> RR12 = 12  advertises second best
> RR21 = 21  advertises second best
> RR22 = 22  advertises best
>
> If the tie breaker reaches step (f),
> C1 will choose second best and C2 will choose best.
>
> The rule I state will prevent the inconsistency.
>
> I assume that the IGP metric problem at the RRs
> has been fixed such that each RR plane
> sees the same IGP metric as its mates.
>
> --
> Jakob Heitz.
>
>
>> -----Original Message-----
>> From: Robert Raszuk [mailto:raszuk@cisco.com]
>> Sent: Sunday, March 27, 2011 3:26 PM
>> To: Jakob Heitz
>> Cc: grow@ietf.org; IETF IDR
>> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist:
>> risk of inconsistent path selection
>>
>>
>> Exactly. So what is the problem within this thread which you
>> claim that
>> clients may "risk of inconsistent path selection" ?
>>
>> R.
>>
>>> This is standard BGP if the IGP metrics are equal.
>>>
>>> --
>>> Jakob Heitz.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Robert Raszuk [mailto:raszuk@cisco.com]
>>>> Sent: Sunday, March 27, 2011 3:17 PM
>>>> To: Jakob Heitz
>>>> Cc: grow@ietf.org; IETF IDR
>>>> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist:
>>>> risk of inconsistent path selection
>>>>
>>>> Jakob,
>>>>
>>>>    >   To prevent clients in different clusters from choosing
>>>>    >   different bestpaths based on tie breaker (f):
>>>>
>>>> Can you restate what is the problem with the above ?
>>>>
>>>> Today clients would chose different best paths when IGP
>> metric to one
>>>> next hop is closest on one to NH1 and closest on the other to
>>>> NH2. And
>>>> this check happens well above step (f).
>>>>
>>>> How is this at all related to the diverse path draft like
>> the subject
>>>> could indicate ?
>>>>
>>>> Thx,
>>>> R.
>>>>
>>>>
>>>>
>>>>> Route selection tie breakers in RFC 4271 state:
>>>>>
>>>>>          f) Remove from consideration all routes other than
>>>> the route that
>>>>>             was advertised by the BGP speaker with the lowest BGP
>>>>>             Identifier value.
>>>>>
>>>>>          g) Prefer the route received from the lowest peer address.
>>>>>
>>>>> Suppose RR Planes use different BGP Identifier values.
>>>>> If they use the same BGP Identifier, a similar argument
>>>>> can be made for peer address.
>>>>>
>>>>> To prevent clients in different clusters from choosing
>>>>> different bestpaths based on tie breaker (f):
>>>>>
>>>>> The RR Plane that advertises the best path MUST be configured
>>>>> with a BGP Identifier higher than that of the RR Plane that
>>>>> advertises the 2nd best. This must be higher than that of
>>>>> the Plane that advertises the 3rd best and so on.
>>>>>
>>>>> I'm not sure if this rule completely solves the problem.
>>>>> If not, then the "Edge_Discriminator attribute" proposed
>>>>> by draft-pmohapat-idr-fast-conn-restore may be required.
>>>>> Also, this would need to be applied before rule (f).
>>>>>
>>>>> --
>>>>> Jakob Heitz.
>>>>>
>>>>> _______________________________________________
>>>>> GROW mailing list
>>>>> GROW@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/grow
>>>>>
>>>>
>>>>
>>
>>