Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 1 Oct 2002 14:14:36 -0400

Alex,
  The assumption with multi-path in my mind is that both routes have
equal "weight" in such attributes as AS-PATH (number of ASs)  
and so on, and the route selection criteria gets down to the BGP ID/Router
ID as the tie breaker. In this case, instead of picking one route we pick
both 
routes and add them to the Routing Table, creating the forwarding multi-path
issues. We here are discussing various permutations of this result that
could work or not work depending on specifics of the two routes. By adding
various rules to limit how we pick/allow the multiple routes, we reduce our
chances for hitting topological problems.

IMHO,
Ben

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Tuesday, October 01, 2002 12:40 PM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [email-masked]
> Subject: Re: issue 11
> 
> 
> Jonathan,
> 
>   At the minimum, the text would need to say what _BGP_ routes are
>   considered equal and can be used for load balancing. We don't
>   want the reader to mistakenly assume that, e.g., paths with
>   a longer AS_PATH can be used for load-balancing.
> 
> -- 
> Alex
> 
> Tuesday, October 01, 2002, 8:14:50 AM, Natale, Jonathan wrote:
> > 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:[email-masked]] 
> > Sent: Tuesday, October 01, 2002 10:49 AM
> > To: Natale, Jonathan
> > Cc: [email-masked]
> > 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:[email-masked]] 
> >> Sent: Monday, September 30, 2002 6:39 PM
> >> To: 'Alex Zinin'; Yakov Rekhter
> >> Cc: [email-masked]
> >> 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:[email-masked]]
> >> > Sent: Monday, September 30, 2002 2:21 PM
> >> > To: Yakov Rekhter
> >> > Cc: [email-masked]
> >> > 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
> >> > 
> >> > 
> 
>