RE: issue 11

["Natale, Jonathan" <[e-mail]>]

If the routes are equal (e.g. only next hop is different) and the speaker is
configured to load balance, the routes are used locally to load balance.
But the same route would be advertised to other peers as would be if load
balance was not configured.  So it is out of scope, just as administrative
distance is out of scope (decided previously).

Of course you could aggregate as described below, but I don't see the point.


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, October 01, 2002 10:49 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 11 

Jonathan,

> I disagree, this does not reflect current implementations that I know of.

How do implementations that you know of handle this ?

yakov.

> Does anybody's implementation do this? 
> 
> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> The following paragraph somewhere in the document may help resolve the
> issue:
> 
> "If more than a single BGP route to the same destination prefix are
> selected to be used locally by a speaker (e.g. for the load sharing
> purposes), such a BGP speaker SHOULD form an aggregate of all such routes
> for the purpose of advertising this prefix to other BGP peers. Route
> aggregation rules are specified in section 9.2.2.2."
> 
> Dimitry
> 
> > -----Original Message-----
> > From: Alex Zinin [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 2:21 PM
> > To: Yakov Rekhter
> > Cc: [e-mail]
> > Subject: Re: issue 11
> > 
> > 
> > Yakov,
> > 
> > [...]
> > >>    Multipath is
> > >>   something that is normally in the heart of a routing 
> > protocol. There
> > >>   should be a good reason to want something like this in a separate
> > >>   document. Do we have one in this case?
> > 
> > > Time. If we are interested in getting the base spec completed within
> > > the timeframe outlined in the current charter, we can't add
> > > substantial new material to the spec. 
> > 
> > I share the concern about time. However, the issues related to best
> > path calculation, multipath included, seem to me to be quite important
> > from the perspective of interoperability and description of further
> > extensions. Maybe if we the chairs could get the right people together
> > and facilitate the process (ADs would definitely contribute to buying
> > the libations), such a design team could come up with solid stuff
> > within a month?
> > 
> > BTW, regarding the part of the spec describing the best path selection
> > algo, I remember there was a concern that it didn't really describe
> > what vendors actually did. Is it still the case?
> > 
> > Alex
> > 
> >