IETF Logo Mail Archive

Re: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft

"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Thu, 23 July 2009 10:11 UTC

Return-Path: <Ilya.Varlashkin@de.easynet.net>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A582F3A6894 for <idr@core3.amsl.com>; Thu, 23 Jul 2009 03:11:15 -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 7OoaxWqjnADV for <idr@core3.amsl.com>; Thu, 23 Jul 2009 03:11:15 -0700 (PDT)
Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id A35D93A6887 for <idr@ietf.org>; Thu, 23 Jul 2009 03:11:14 -0700 (PDT)
Received: from fe01kgham.de.easynet.net ([194.163.250.17] helo=fe01kgham.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from <Ilya.Varlashkin@de.easynet.net>) id 1MTvDW-0003ra-It; Thu, 23 Jul 2009 12:08:02 +0200
Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by fe01kgham.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:08:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jul 2009 12:08:01 +0200
Message-ID: <D12350C326DF61448B1AE6B46C453F0E25BDD8@ex01kgham.adoffice.local.de.easynet.net>
In-Reply-To: <4A680D87.80501@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft
thread-index: AcoLZTia0po4va2SQ6+0hswoPONwBAAFte1A
References: <200907230422.n6N4MgYa021490@harbor.orleans.occnc.com> <4A680D87.80501@cisco.com>
From: Ilya Varlashkin <Ilya.Varlashkin@de.easynet.net>
To: raszuk@cisco.com, idr List <idr@ietf.org>
X-OriginalArrivalTime: 23 Jul 2009 10:08:02.0763 (UTC) FILETIME=[76EE59B0:01CA0B7D]
Subject: Re: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 23 Jul 2009 10:11:15 -0000

> -----Ursprüngliche Nachricht-----
> Von: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] Im 
> Auftrag von Robert Raszuk
> Gesendet: Donnerstag, 23. Juli 2009 09:13
> An: curtis@occnc.com
> Cc: idr List
> Betreff: Re: [Idr] 
> draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft
> 
> Hi Curtis,
> 
> I think your assessment of the draft is right. The original 
> issue has been raised by the problem of considering next hop 
> as valid and reachable IP reachability wise without any 
> correlation with MPLS LSP to such next hop which was a must 
> and a prerequisite for some applications to work.
> 
> In my opinion this is a valid problem, but this is not a BGP issue.
> 
> Underlying transport (for example MPLS LDP or MPLS-TE) should 
> only expose valid and reachable LSPs to it's RIB so when BGP 

Robert,

in some scenarios (e.g Inter-AS MPLS stuff) labels are distributed by BGP itself. Also, LDP may have received all correct info from the neighbors, but failed to install it into forwarding plane (either due to hardware failure or a software bug). Having experienced this with routers from two different manufacturers, I believe it would be really benefical if BGP could perform a bit more extended checks rather than just looking into control plane. I understand that issue is more of "local type" (e.g. hardware failure) rather than protocol itself, but considering reality (bugs do happen and hardware does fail) it's very desirable that BGP specs at least encourage implementors to make more effort in validating next-hop. And this is why I believe IDR is correct WG for this draft.

Cheers,
iLya

v2.23.0 | Report a Bug | By Email