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