Subject: [Idr] Suggested breakdown of problem space for multiple bgp paths

From: Jeffrey Haas <[email-masked]>
Date: Thu, 31 Aug 2006 12:42:55 -0400

A lot of the churn on the list on this topic seems to be over the
different problem spaces each solution is trying to address.  I'd
like to see them presented clearly so we're sure we're all talking
about the same things:

1. Ability to send multiple routes for purposes of route oscillation
   suppression.

2. Ability to send multiple routes as a "route-server".

3. Ability to send multiple routes for ecmp purposes.

While the solution space for these three issues has large amounts
of overlap, I think the predisposition of a solution towards 
a subset of these problem spaces has been tainting arguments in
this thread.

The solution spaces thus far are:

1. Inject multiple routes keyed on nexthop(s) and NLRI

2. Inject multiple routes keyed abstractly on a route identifier of
   bgp session significance.

I've presented the argument that the lack of a "used for forwarding"
bit is problematic.  I've constructed an example case that I believe
illustrates this, and I'll send that as a separate e-mail.

Curtis has made an argument where distinguishing on nexthop(s) as a key
alone is incompatible with the route server argument.  I agree.

The authors of the ecmp draft have made an argument regarding the fate-sharing
of ecmp routes.  I believe the IDR members agree with the basics of this
argument: If you're going to use multiple routes for forwarding, these routes
have a fate-sharing relationship.  You can't process these routes separately.
You also can't advertise them externally of whatever solution we come up with
for multiple routes without some form aggregation.  Some forms of this
aggregation are, IMO, problematic.

As we discuss any possible solution, I suggest we keep these things in
mind.

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr