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
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 27 Sep 2002 10:46:21 -0400

> practice. Failing this, many large vendors would be considered

They aren't non-compliant.  They implement the base specification and
probably can shut off their multipath extensions.

Documents outside of the base specification can and do extend the
base specification.  Consider Confederations - it changes the
AS_PATH and the behavior of route selection.  Technically, someone
who implements confederations isn't compliant with the base spec.
But similarly, you can shut off confederations and still interoperate.

With this in mind, would you be happy documenting the base specification
and save documenting the multipath extension until later?

And also note that vendor-specific extensions aren't also compliant
with the spec.  However, if their implementation *can* be compliant
by shutting off those features, thats good enough.

-- 
Jeff Haas 
NextHop Technologies