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

Mike Benjamin <mikeb@gblx.net> Thu, 23 July 2009 17:17 UTC

Return-Path: <mikeb@gblx.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 D19043A6B77 for <idr@core3.amsl.com>; Thu, 23 Jul 2009 10:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.512
X-Spam-Level:
X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.1]
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 KO0O6FZEYmLi for <idr@core3.amsl.com>; Thu, 23 Jul 2009 10:17:46 -0700 (PDT)
Received: from pinky.disturbed.org (host-216-9-185-208.orbitelcom.com [216.9.185.208]) by core3.amsl.com (Postfix) with ESMTP id 032C23A6AD3 for <idr@ietf.org>; Thu, 23 Jul 2009 10:17:45 -0700 (PDT)
Received: from pinky.disturbed.org (localhost [127.0.0.1]) by pinky.disturbed.org (8.14.2/8.14.2) with ESMTP id n6NHGu72093430; Thu, 23 Jul 2009 10:16:57 -0700 (MST) (envelope-from mikeb@gblx.net)
Received: (from mikeb@localhost) by pinky.disturbed.org (8.14.3/8.14.3/Submit) id n6NHGu2O093428; Thu, 23 Jul 2009 10:16:56 -0700 (MST) (envelope-from mikeb@gblx.net)
X-Authentication-Warning: pinky.disturbed.org: mikeb set sender to mikeb@gblx.net using -f
Date: Thu, 23 Jul 2009 10:16:56 -0700
From: Mike Benjamin <mikeb@gblx.net>
To: Robert Raszuk <raszuk@cisco.com>
Message-ID: <20090723171656.GB80638@gblx.net>
References: <200907230422.n6N4MgYa021490@harbor.orleans.occnc.com> <4A680D87.80501@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4A680D87.80501@cisco.com>
User-Agent: Mutt/1.4.2.3i
Cc: idr List <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 17:17:46 -0000

On Thu, Jul 23, 2009 at 12:13:11AM -0700, Robert Raszuk wrote:
: 
: 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.

Only exposing valid and reachable LSPs to the RIB would push the
OAM aspect of problem #2 back to MPLS if you are using RSVP-TE or
LDP for label exchange.  As Ilya has pointed out, BGP is also used
for label exchange, meaning you've also pushed the requirement to
BGP.

Issue #1 also still exists due to the IGP presenting the route.  The
"fix" currently would be to not use IGP learned addresses for BGP
peering.  This means things like static routes tied to LSPs that
don't seem like the correct answer to me.

The scenario that presents this problem is not isolated to L3VPNs.
A network that uses IGP only for control plane in order to establish;
BGP for route exchange, and another protocol for transport
(MPLS/L2TP/etc..), also presents the problem.  In such a network
design, informing BGP that that only the transport protocol installed
routes may be used to resolve nexthops would be required.

--mikeb

 
: 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

--
Mike Benjamin   -     +1-602-744-3403
mikeb@gblx.net  - Development Engineering
Global Crossing -       Phoenix, USA