Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 1 Oct 2002 11:33:13 -0400

Jonathan:

See Below

> -----Original Message-----
> From: Natale, Jonathan [mailto:[email-masked]]
> Sent: Tuesday, October 01, 2002 11:15 AM
> To: 'Yakov Rekhter'; Natale, Jonathan
> Cc: [email-masked]
> Subject: RE: issue 11 
> 
> 
> 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.

It would be smarter to assign the next hop address to a virtual 
interface (e.g. Loopback Interface address) thus if the peer has two 
physical interfaces to current router, there is only one route.
Thus the load balancing issue is transparent to the BGP routing
and only obvious in the forwarding plane. Also, this is localized to
the load balancing to be contained between the current router and an
adjacent router. Once we get into load balancing between the current
router and different routers we get into all kinds of what if conditions.

Just another twist to solving load balancing issues.

> 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).
>
So the current peer advertises two routes with same prefix and different
next hops. Would'nt the second route overtake the first route in the
peer's routing table such that there will only be one route present in
the peer's routing table? If so, how will that work for load balancing?
 
> Of course you could aggregate as described below, but I don't 
> see the point.
> 
>

Aggegation is good for reducing routing table size, but not to solve 
multi-path issues. IMHO.

Ben

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

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 01 Oct 2002 08:56:57 -0700

Ben,

> and only obvious in the forwarding plane. 

And if it is transparent to the BGP routing, then there is no
need to have it in the base spec. Agreed ?

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 1 Oct 2002 09:42:55 -0700

Yakov,

> need to have it in the base spec. Agreed ?

Note that what Ben described above is not BGP multipath, but
load-balancing based on IGP multipath, and right, _this_ one doesn't
belong in the spec.

Alex

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 01 Oct 2002 20:24:46 -0400

> load-balancing based on IGP multipath, and right, _this_ one doesn't

Alex,

In addition to IGP multihop, there are two cases of BGP multipath.

In IGP multihop there is one BGP advertisement but to ways to reach th
BGP NEXT_HOP via the IGP.

In one case of BGP multihop, two (or more) IBGP routers peering with
the same external AS have equal routes to a destination and are an
equal cost away from a third router.  BGP multihop is applicable to
that third router.  Without BGP multihop, BGP would normally pick the
BGP NEXT_HOP of the advertisement from only one of those IBGP peers
(using BGP Identifier) and use that.  The IGP lookup would yield one
next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
or more IGP next hop).

The second case is where all of the candidates routes for BGP
multipath are external.  Seldom does IGP multipath come into play for
EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
split among two (or more) routers in the same AS.

If in EBGP multipath you split among routers in difference AS, an
aggregate should be formed.  This is still prior to the IGP cost rule
in the route selection.

Normally one would not combine IBGP and EBGP in multihop given that
the decsion point for multihop is after "d" in 9.1.2.2.  If the
multihop decision was prior to "d", then two routers each with an
external peering would forward some of the traffic to each other and
for some src/dst pairs, they'd form a loop.  [So don't do that!]

This is getting to be a lot to add to the base spec.  I hope we've
convinced you that we should put it in another document.

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Wed, 2 Oct 2002 15:47:29 -0700

Curtis,

  Agree with your overview of BGP multipath.

  Regarding a separate document for this... I'm trying to find a
  convincing reason that would overweight the importance of this part,
  something like "this is really new and unexplored", or "it would
  really take months for the WG to converge on", etc. But it seems
  that we know what the text should talk about and what the
  considerations are (such as ECMP load sharing that you talk about in
  your other message). If this is so, then I ask myself why is it a
  problem to put this in the spec? Maybe yourself and the chairs could
  take me off the stage and beat me up behind the curtain so I could
  then come back to the list and say "a separate doc makes sense".
  I have no problem admitting I was wrong...

-- 
Alex