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