[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

In message <92c950310609020835x74ad616s7e69dd9340101f71 at mail.gmail.com>
"Glen Kent" writes:
>  
> Curtis,
>  
> > > > > Path 1 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 100 NEXT_HOP 1.1.1.1
> > > > >
> > > > > Path 2 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 189 NEXT_HOP 1.1.1.1
> > > >
> > > > If this came from the same router then complain because the sender of
> > > > this is broken.
> > >
> > > This is exactly what a receiver will receive if add-paths is
> > > implemented, because you dont differentiate between paths. You blindly
> > > flood all the paths that you receive.
> >
> > It would not receive this from one router.  That one router would have
> > to pick the route with the better LOCAL_PREF.  I'm assuming we are not
> > modifying the way LOCAL_PREF works.
>  
> You probably didnt understand the add-paths proposal otherwise you
> wouldnt have said this.
>  
> The idea behind add-paths is to flood every BGP advertisment to all
> its peers. You dont run your decision process to decide on the routes
> that need to be flooded. In this case, the router in question, will
> not pick the route with a better LOCAL_PREF; it will blindly flood
> both the paths to everyone.
>  
> So, contrary to what you said in your earlier mail, a reciever
> _cannot_ complain if it receives such advertisements as the sender is
> conforming to the add-paths proposal and it definitely aint broken.
>  
> Unless of course, if you're suggesting that add-paths proposal is
> inherently broken .. ? Was this your intent?


No where in the add-paths document, at least the -05 version does it
say anything like that.  The only mention of the decision precoes is
in the intro.


   1. Introduction

   The BGP specification [RFC4271] defines an "Update-Send Process" to
   advertise the routes chosen by the Decision Process to other BGP
   speakers.  No provisions are made to allow the advertisement of
   multiple paths for the same address prefix, or Network Layer
   Reachability Information (NLRI).  In fact, a route with the same NLRI
   as a previously advertised route implicitly replaces the previous
   advertisement.

   In this document we propose a BGP extension that allows the
   advertisement of multiple paths for the same address prefix without
   the new paths implicitly replacing any previous ones.  The essence of
   the extension is that each path is identified by a path identifier in
   addition to the address prefix.

This does not advocate eliminating the decision process, only allowing
more than one next-hop.  Common practice with BGP ECMP is to consider
any pair of routes that tie at the IGP comparison step to be equal and
use both for forwarding.  This allows advertising both.  

OTOH more explanation of this brief applicability statement is needed
since here they suggest advertising routes not used.

   7. Applications

   The BGP extension specified in this document can be used by a BGP
   route reflector [RFC2796] or BGP Confederation ASBR [RFC3065] to
   advertise more than just the best path in order to eliminate
   persistent route oscillations [RFC3345], or to help achieve optimal
   routing in a network.

   Other applications are for further study.

RFC3345 may provide a hint in that the route oscillation cases involve
the decision tie break using MED.  It is possible that the authors
expected the reader to be familiar with this references and in this
case recognize that advertising routes where MED break the tie would
be sufficient to stop the oscillation.

If this was the authors intent, which it may or may not be, then it
would be better if they explicitly stated the details of this usage.

Again, add-paths is too terse.  Again, as Jeff pointed out we need to
discuss the problem space first, then look at how solutions fit into
the problem space.


> > > If the receiver has to ignore all such paths then why is add-paths
> > > sending them in the first place?
>  
> The question still stands unanswered.


Add-paths is not sending routes blindly as I pointed out above.


> > > No, you didnt get my question at all. My point is that we need to
> > > explicitly mark the route being used in fwding, as otherwise the peer
> > > receiving multiple paths can never know which path is being used by
> > > the router advertising these routes. You need this information for
> > > obvious reasons. See Jeffs mail for more details.
> >
> > This is a different usage.  I'm assuming that a multipath means ECMP.
> > You seem to be assuming that all advertisements are being sent
> > including ones that are not being used and then complaining that there
> > is no way to determine which one is being used.
>  
> Yes, I am. Please contact me or Jeffrey Hass (or any one of the
> co-authors) offline if you have any doubts on this.

Since this is a discussion of the problem space it can go on list.

> > > None of the proposals currently do this which to me is rather blasphemous.
> > >
> > > Glen
> >
> > Maybe thats because neither of the proposals intend to send paths that
> > are not being used.  I think that the WG needs to decide whether that
>  
> Really? Are you sure of what you're saying? I am marking a copy to
> Enke Chen and Joel Halpern who will help you clear this gross
> misunderstanding that their drafts are only meant to advertise ECMP
> routes.
>  
> I find the fact rather disturbing that you have been commenting on
> both of these drafts without even understanding what each one proposes
> to do.

Again, I just read the drafts.  I'm not connected with either set of
authors.  Maybe a discussion of the problem space is needed.  I had
considered the BGP ECMP case.  Apparently the primary focus of
add-path is suppressing RR and confed oscillations.  In private email
Joel pointed out that an RS is a case where a router might want to
send everything without running a decision process at all.

> If the drafts are _only_ meant for ecmp then i see no text that talks
> of how these proposals work with non add-paths/multiple_hops capable
> peers.
>  
> Read ecmp-routes-in-bgp draft if you want to understand my point. The
> instant you cross an ECMP domain you have to construct a "synthetic"
> (I picked up this term from this draft) aspath that contains all the
> AS numbers.
>  
> Glen

That draft appears to have expired.  There is nothing with ecmp in the
filename, title, or abstract in the internet-drafts abstracts file
except one by George Swallow about MPLS ECMP.

Curtis

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr