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

Curtis Villamizar <curtis@occnc.com> Thu, 23 July 2009 04:25 UTC

Return-Path: <curtis@occnc.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 83C623A69E9 for <idr@core3.amsl.com>; Wed, 22 Jul 2009 21:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 SNwFijEBlOLA for <idr@core3.amsl.com>; Wed, 22 Jul 2009 21:25:37 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6E9A03A694A for <idr@ietf.org>; Wed, 22 Jul 2009 21:25:37 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n6N4MgYa021490; Thu, 23 Jul 2009 00:22:42 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <200907230422.n6N4MgYa021490@harbor.orleans.occnc.com>
To: "John G. Scudder" <jgs@juniper.net>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Tue, 21 Jul 2009 22:57:23 EDT." <56CC1BBE-4437-4FA8-85A6-D4E3E9A9B8C6@juniper.net>
Date: Thu, 23 Jul 2009 00:22:42 -0400
Sender: curtis@occnc.com
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
Reply-To: curtis@occnc.com
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 04:25:38 -0000

In message <56CC1BBE-4437-4FA8-85A6-D4E3E9A9B8C6@juniper.net>
"John G. Scudder" writes:
>  
> On Jul 21, 2009, at 10:08 PM, Curtis Villamizar wrote:
> > Susan Hares wrote:
> >> We have received a request to accept draft-asati-idr-bgp-bestpath- 
> >> selection-criteria-00.txt as an IDR WG document. Please send your  
> >> votes by 8/3/09.
> >> Sue and John
> >
> >
> > The draft that I just fetched (as -01) says:
> >
> >    This Internet-Draft,
> >    draft-asati-idr-bgp-bestpath-selection-criteria-00.txt, has
> >    expired, and has been deleted from the Internet-Drafts directory.
> >
> > I'm not sure how we can take a "vote" with the draft unavailable for
> > review.
>  
> A fair point.
>  
> Rajiv, can you please refresh the draft?
>  
> Curtis, my advanced search engine skills enabled me to find http://tools.ietf.org/html/draft-asati-idr-bgp-bestpath-selection-criteria-00 
>   , which should take care of the practical issue if you don't want to  
> wait until the draft gets refreshed (which I assume will only happen  
> after the IETF due to the pre-IETF draft publication freeze).
>  
> --John


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