Re: issue 11

[Yakov Rekhter <[e-mail]>]

Alex,

> Jeff, et al
> 
>  I'm a little lost here. Considering that BGP multipath:
> 
>   - is implemented by at least two (major) vendors
> 
>   - affects core protocol mechanisms
> 
>   - is important enough to be thoroughly described
>     to avoid implementation bugs
> 
>  why would we not want it in the base spec?

Why not in a separate draft ?

After all, there are quite a few *optional* BGP features that are
implemented by multiple vendors, affect core protocol mechanisms,
and are important enough to be thoroughly described to avoid
implementation bugs, and are not in the base spec, but are in
separate RFCs.

Yakov.

>     
> -- 
> Alex
> 
> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chennai.
 wrote:
> >> % The Loc-RIB SHOULD contain only one route per destination.
> >> % An implementation may choose to install multiple routes to
> >> % a destination (for the purposes of load balancing).
> >> % An implementation doing this MUST ensure that it is
> >> % interoperable with versions that do not, and MUST
> >> % ensure that no routing loops or inconsistent routing
> >> % information is propagated as result of this action. The
> >> % handling of such a configuration, however, is outside the
> >> % scope of this RFC.
> >> 
> >>    It does seem a little too detailed, though!
> 
> > My concern is not that this is rope to allow operators to hang themselves
> > with - this is a gatling gun that allows implementers to try to
> > guess at useful rules and hose the Internet.  BGP, as a protocol,
> > is already prone to long-lived loops.  Lets not make it easier to
> > do this in a way thats harder to troubleshoot.
> 
> > I haven't thought about this in large amounts of detail, but some
> > quick observations on what could be done to actually implement
> > this:
> 
> > o The routes should be equally preferable - i.e. they need to enter
> >   the tie-breaking process.
> > o They should have the same AS_PATH
> > o Perhaps the path attributes should only be allowed to differ on
> >   NEXT_HOP.
> 
> > *If* the above are true, then re-announcing any of the routes used
> > in the load-balancing should work fine as long as the re-announcement
> > is going to be a first-party nexthop.  If you have a third-party
> > nexthop, then you might end up with inconsistant forwarding.
> 
> > I would propose that this might be something worth investing some
> > time over, but it shouldn't be mentioned in the base spec.
> 
> >> Sivanand
> 
>