Subject: RE: issue 11

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

Sivanda:
  Actually you raise an interesting point. If we assume that every item
mentioned in a spec requires compliancy, then if you add this feature
to the spec there might be someone out there that did not implement it
mainly because they felt it was not needed. Thus, all of a sudden they
will fail the compliancy test and will have to do more work to be approved.
That is another big reason why you should not add this kind of stuff, unless
you are sure that everyone out there has it in their software.

Personnally, I dont think every item in an RFC must be implemented for the
vendor to be compliant. But thats a personal opinion.

Regards,
Ben

> -----Original Message-----
> From: Sivananda Ramnath - CTD, Chennai. [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 10:41 AM
> To: Jeffrey Haas; Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: RE: issue 11
> 
> 
> 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
> > 
>