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 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
> 