Subject: RE: issue 11

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Fri, 27 Sep 2002 20:11:05 +0530

Hello,

   There are implementers today who have already implemented this. It's not
a new concept I am proposing here, merely stating the existence of a current
practice. Failing this, many large vendors would be considered
non-compliant.

   I completely agree with you on the potential hazards of doing this
incorrectly; that said how do we resolve this issue while taking care not to
declare existing implementations to be non-compliant ?

Sivanand
([email-masked])

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 7:55 PM
> To: Sivananda Ramnath - CTD, Chennai.
> Cc: Abarbanel, Benjamin; [email-masked]
> Subject: Re: issue 11
> 
> 
> 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
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>