Re: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt

Richard Li <renweili@huawei.com> Thu, 24 June 2010 17:29 UTC

Return-Path: <renweili@huawei.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 D98F23A67E7 for <grow@core3.amsl.com>; Thu, 24 Jun 2010 10:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uovMufD5J2tv for <grow@core3.amsl.com>; Thu, 24 Jun 2010 10:29:38 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 982853A6837 for <grow@ietf.org>; Thu, 24 Jun 2010 10:29:37 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4J00DYO4LLMO@usaga04-in.huawei.com> for grow@ietf.org; Thu, 24 Jun 2010 12:29:46 -0500 (CDT)
Received: from R73802B ([10.193.34.55]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4J001ZP4LJ7G@usaga04-in.huawei.com> for grow@ietf.org; Thu, 24 Jun 2010 12:29:45 -0500 (CDT)
Date: Thu, 24 Jun 2010 10:29:43 -0700
From: Richard Li <renweili@huawei.com>
In-reply-to: <4C230C0B.8070303@cisco.com>
To: raszuk@cisco.com, grow@ietf.org
Message-id: <02a501cb13c2$d69715c0$3722c10a@china.huawei.com>
Organization: Huawei Technologies
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcsTcKxowCrhUg9USkqz18CYqNC7+gATWK1A
References: <20100623083005.61D6B3A6A65@core3.amsl.com> <025b01cb1331$ae2ad900$3722c10a@china.huawei.com> <4C230C0B.8070303@cisco.com>
Subject: Re: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: renweili@huawei.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: Thu, 24 Jun 2010 17:29:40 -0000

Hi Robert,

Certainly RR works with clusters, but this is not something essential to my
concern.

In order to make it work, all planes MUST have a consistent/same view about
whether a path P1 is better than another path P2 for any two paths P1 and P2
associated to the same route so that they will have the same ordering in
terms of "n-best/better" path. Only under this condition, the first plane
will distribute the best path, the second plane will distribute the second
best path, the third plane will distribute the third best path, and so on.
Otherwise, all the paths won't be correctly distributed since some paths
will be lost (e.g. the P3 in my original example).

Let's go back to your remarks. You have assumed three conditions:
(1) RRs have equal IGP point of the network
(2) IGP metric consideration is disabled for best path calculation 
(3) RRs have a way to learn what the best path of other plane is.

Well, if the IGP metric is taken out of consideration, it will work (but IGP
metric is already built into many production codes for best path selection).
But I am not convinced with the other two conditions. For the first
condition, it may be too much for an operator to have to deploy RRs with the
same IGP metric. Technically speaking, it is easy to make a topology to have
RRs with different IGP metrics. For the third condition, there hasn't been
such a spec about how to learn what the best path of another plane is.

Anyhow, I would appreciate it if you spell it out in length about path
consistency in your next draft.

Regards,

/RL






-----Original Message-----
From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of
Robert Raszuk
Sent: Thursday, June 24, 2010 12:41 AM
To: grow@ietf.org
Subject: Re: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt

Hi Richard,

Your description is missing the concept of RR clusters.

Each plane should be present in each cluster. And all RRs serving paths in a
given cluster need to either have equal IGP point of the network, disabled
IGP metric consideration for best path calculation or have a way to learn
what the best path of other plane is.

With this in mind your statement

"With different IGP topology, one RR may view a path as the second best
while another RR may view the same path as the third best."

will not take place as the above conditions make sure that there is path
consistency on a per cluster basis.

Note also that just like in normal IPv4/IPv6 networks where tie breaker is
IGP metric there is no need for best path consistency across clusters
without compromising loop free BGP property.

If you agree with the above I will make sure that the text in the draft is
more clear on that.

Many thx,
R.


> Let's assume that three planes of RR are deployed: The first plane 
> distributes the best path for each route as usual, the second plane 
> for the second best, and the third plane for the third best. Using 
> your example, we take the IGP distance as the equally-good path 
> tie-breaker.  With different IGP topology, one RR may view a path as 
> the second best while another RR may view the same path as the third 
> best. For example, let's consider a route R with paths P1, P2, P3, 
> where P2 and P3 are equally good and thus need to be broken by a tie 
> breaker.  On the first plane RR, P1 is viewed as the best, and is thus 
> distributed as we hoped. On the second plane RR, P2 is viewed as the 
> second best and is thus distributed. On the third plane RR, however, 
> P2 is viewed as the third best and the P3 is viewed as the second best,
and thus P2 is distributed, but this is not something we hoped to see.
>
> In order to make it work, all RRs on all planes should put all the 
> paths in the same ordering, otherwise it will not correctly distribute 
> the nth best path. But can you do that under all circumstances? The 
> above example shows you can't, unless I have missed something.
>
> Regards,
>
> Renwei
>
>
>
>
>
> -----Original Message-----
> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf 
> Of Internet-Drafts@ietf.org
> Sent: Wednesday, June 23, 2010 1:30 AM
> To: i-d-announce@ietf.org
> Cc: grow@ietf.org
> Subject: [GROW] I-D 
> Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Global Routing Operations Working 
> Group of the IETF.
>
>
> 	Title           : Distribution of diverse BGP paths.
> 	Author(s)       : R. Raszuk, et al.
> 	Filename        : draft-ietf-grow-diverse-bgp-path-dist-01.txt
> 	Pages           : 20
> 	Date            : 2010-06-23
>
> The BGP4 protocol specifies the selection and propagation of a single 
> best path for each prefix.  As defined today BGP has no mechanisms to 
> distribute paths other then best path between it's speakers.  This 
> behaviour results in number of disadvantages for new applications and
services.
>
> This document presents an alternative mechanism for solving the 
> problem based on the concept of parallel route reflector planes.  It 
> also compares existing solutions and proposed ideas that enable 
> distribution of more paths than just the best path.
>
> This proposal does not specify any changes to the BGP protocol definition.
> It does not require upgrades to provider edge or core routers nor does 
> it need network wide upgrades.  The authors believe that the GROW WG 
> would be the best place for this work.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-grow-diverse-bgp-path-d
> ist-01
> .txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow