Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 1 Oct 2002 10:22:26 -0400

Dimitry:
  Although forming an aggregate may solve the problem of unpredictable 
route path forwarding. It will cause some attributes to be lost and
thus not offer the peer the proper networking visibility. If we want 
to solve the multipath issue we must add rules for example, it works
reliable
well if the same AS providor is providing the multipath routes from its 
various links/routers. Else, it will be less deterministic and potentially
prone to problems such as routing loops and/or degradation of latency.

But in a nutshell I think Yakov does not want to start this topic here and
now. Although a good item to discuss in future revisions and possibly solve.

Ben

> -----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
> > 
> > 
>