Separate document for multipath - or part of BGP spec
Curtis Villamizar <curtis@workhorse.fictitious.org> Thu, 17 October 2002 15:59 UTC
Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15575 for <idr-archive@ietf.org>; Thu, 17 Oct 2002 11:59:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6DF05912BF; Thu, 17 Oct 2002 12:00:41 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3514A912C0; Thu, 17 Oct 2002 12:00:41 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F3FE912BF for <idr@trapdoor.merit.edu>; Thu, 17 Oct 2002 12:00:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DAC815DDB3; Thu, 17 Oct 2002 12:00:26 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 52B505DDAC for <idr@merit.edu>; Thu, 17 Oct 2002 12:00:25 -0400 (EDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA87883; Thu, 17 Oct 2002 11:59:48 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200210171559.LAA87883@workhorse.fictitious.org>
To: idr@merit.edu
Cc: curtis@fictitious.org
Reply-To: curtis@fictitious.org
Subject: Separate document for multipath - or part of BGP spec
Date: Thu, 17 Oct 2002 11:59:48 -0400
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-idr@merit.edu
Precedence: bulk
After some discussion initiated by Alex we ended up with the following text on BGP multipath. If we can get consensus on text to be added to the BGP base spec then we'll add text. If not, we'll omit any mention of BGP multipath. We seem to have rough consensus among a small number of people. Curtis [new subesection] BGP specifies how to select the single best route. OSPF specifically defines procedures for handling equal cost multipath (ECMP) [cite OSPF]. The same technique has been applied to ISIS. A similar technique has been used with BGP. Variations exist but the decision to support BGP multipath, the specific variation of BGP multipath, or not to support it, does not affect interoperability. A naive implementations of ECMP can cause severe performance degradation for TCP flows. To avoid this, implementations of BGP multipath SHOULD maintain packet ordering within microflows as described in [cite rfc2991, rfc2992]. BGP multipath, if implemented, SHOULD be disabled by default. In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there are two variations of BGP multipath described here. A BGP implementation may offer both, either one, or neither variation of BGP multipath. Other variations of BGP multipath may exist, but no guarantees can be made in this protocol specification of their properties or impact on interoperability. Where IGP multipath is used, there is an interaction with BGP learned routes. The lookup of a BGP NEXT_HOP in the IGP can result in the selection of an IGP multipath entry. This is not a variation of BGP multipath. When this occurs, one BGP route is slected as the best but there is more than one way to reach the BGP NEXT_HOP via the IGP. In one variation of BGP multipath, a set of more than one IBGP routers peering with the same external AS have equal routes to a destination and are an equal IGP cost away from a second set of one or more routers. BGP multipath is applicable to the latter set of routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of the advertisement from only one of those IBGP peers (using BGP Identifier) and use only that BGP route. With BGP multipath, BGP uses the BGP NEXT_HOP of more than one of these equal cost advertisements, yielding more than one BGP NEXT_HOP. Each BGP NEXT_HOP has a different IGP next hop (one or more IGP next hop if IGP multipath is in use). The second case is where all of the candidates routes for BGP multipath are external and learned by a single BGP peer. Without BGP multipath this peer would select only one of the BGP routes and obtain only one BGP NEXT_HOP. With BGP multipath, more than one equal cost route is selected yielding more than one BGP NEXT_HOP. Seldom does IGP multipath come into play when looking up an EBGP NEXT_HOP but could in principle be applicable. If in EBGP multipath traffic is split among routers in difference AS, an aggregate SHOULD be formed so as to propogate a route with an accurate AS_PATH. If the resulting aggregate is not more specific than the components, the AS_SET SHOULD NOT be dropped. The decsion point for multipath is after step "d" in Section 9.1.2.2 (prefer externally learned routes). IBGP learned and EBGP learned routes MUST NOT be combined in multipath. If the multipath decision is prior to "d", then two routers each with an external peering would form a routing loop. The decision point for multipath is generally after step "e" in Section 9.1.2.2. Some relaxation of the "equal cost" rule (also applicable to IGP multipath) is possible. In addition to the equal cost BGP NEXT_HOPS available at BGP route selection, if the IGP next hop for other BGP NEXT_HOPs are of lower cost, then those may be used as well. This relaxation of the step "e" is possible but is not widely implemented (and may not be implemented at all).
- Separate document for multipath - or part of BGP … Curtis Villamizar
- Re: Separate document for multipath - or part of … Yakov Rekhter
- RE: Separate document for multipath - or part of … Natale, Jonathan
- RE: Separate document for multipath - or part of … Russ White