Re: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft
<bruno.decraene@orange-ftgroup.com> Thu, 23 July 2009 09:51 UTC
Return-Path: <bruno.decraene@orange-ftgroup.com>
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 6807D3A6839 for <idr@core3.amsl.com>; Thu, 23 Jul 2009 02:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6]
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 an0Dg8DXbdfM for <idr@core3.amsl.com>; Thu, 23 Jul 2009 02:50:59 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 19CDE3A67A2 for <idr@ietf.org>; Thu, 23 Jul 2009 02:50:58 -0700 (PDT)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 11:37:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jul 2009 11:37:48 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC2404087DE@ftrdmel0.rd.francetelecom.fr>
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: AcoLbON8ipcwj6XTTv++LRyW0yil9AACxi4A
References: <200907230422.n6N4MgYa021490@harbor.orleans.occnc.com> <4A680D87.80501@cisco.com>
From: bruno.decraene@orange-ftgroup.com
To: raszuk@cisco.com, curtis@occnc.com, rajiva@cisco.com
X-OriginalArrivalTime: 23 Jul 2009 09:37:05.0773 (UTC) FILETIME=[241429D0:01CA0B79]
Cc: idr@ietf.org
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 09:51:00 -0000
Hi Rajiv, all, Following Robert's comment regarding MPLS (wg) dependency, in the section 2 "Route Resolvability Condition - Modification" what about adding the following point between 1) (use the right NH availability info) and 2) (use OAM to check): SHOULD use LDP ordered mode (rather than independent) to check the end to end control plane status. (then forwarding plane status may optionally be checked by the "OAM data-plane liveness mechanisms" that you currently propose in 2) ) Thanks, Regards, Bruno > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk > > 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 does route > validation and resolution it would already be able to choose from valid > and reachable next hops. That would result in no changes to BGP both > protocol and implementation wise. > > So I would recommend to move this draft to mpls wg as essentially only > this transport exhibits the problem described in the spec. > > Cheers, > R. > > > > Fair enough. You're a wizard with that there searchie thingie. > > > > The first rule just seems obvious and out of scope for RFC4271. Is > > the first rule saying much more than "If there is more than one IGP > > instance, pick the right one"? If so is that too obvious to need to > > be stated? > > > > The second rule is a "ping the next hop" rule, or more correctly check > > the OAM status. > > > > It strikes me that if we did the analogous thing for BGP and IP > > routers, we'd be suggesting that a ping of the next hop be performed > > just in case a router along the way wasn't working correctly (which in > > the very early 1990s was a distinct possibility, but I digress). The > > "right answer" for IP then was to make sure IP routers really do work > > at the IP/IGP level, and not triggerred by a BGP prefix reference to a > > particular next hop. > > > > Based on the examples, it looks like the problemm areas are in L3VPN > > using MPLS and LDP. But what if the BGP router is one more hop back > > in the IGP on the left CE side of the diagrams? If so it may not be > > aware of the MPLS LSP. Do things break then? > > > > Are providers really serving up broken L2TP, GRE, or L3 VPNs and if so > > is this the right venue to be addressing the problem? Are we better > > off working around this sort of brokenness in BGP or fixing it in the > > underlying offender (L2TP, GRE, or L3 VPNs, or more correctly > > someone's broken implementation of them)? > > > > Curtis > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft-asati-idr-bgp-bestpath-selection-crit… Susan Hares
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Ilya Varlashkin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… David Freedman
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Stephens, Jamie A
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Joseph Singarayer
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Bonnett Jr, Michael
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Hoffpauir, Jeremy G
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Mike Benjamin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… zubair.ahmad
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Mohan Nanduri
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Rajiv Papneja
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Curtis Villamizar
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… John G. Scudder
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Rajiv Asati (rajiva)
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… UTTARO, JAMES, ATTLABS
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Deng, Guan
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Deng, Guan
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Curtis Villamizar
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Robert Raszuk
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… bruno.decraene
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Ilya Varlashkin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Robert Raszuk
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Ilya Varlashkin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Mike Benjamin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… Mike Benjamin
- Re: [Idr] draft-asati-idr-bgp-bestpath-selection-… KRATTIGER Lukas