Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 27 Sep 2002 16:49:50 -0400

Alex:
  If we mention BGP Multipath, either dedicate a whole section to it or
mention it and provide a reference document that is dedicated to it. Just
saying the details are out of scope is unreasonable.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 4:34 PM
> To: Alex Zinin
> Cc: [email-masked]
> Subject: Re: issue 11 
> 
> 
> 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
> > 
> > 
>