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

[<bruno.decraene at orange-ftgroup.com>]

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 at ietf.org [mailto:idr-bounces at 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 at ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
> 
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr