RE: Separate document for multipath - or part of BGP spec

["Natale, Jonathan" <[e-mail]>]

I think you had proposed adding some type of blurb that basically said that
this is out of
scope. I think it is out of scope.  I also think it is sufficiently complex
to warrant a
separate draft (doesn't one already exist?).

Also, in Bgp multipath it is important that there is still only one route
selected for
re-advertisement.  The text below does not indicate this.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, October 17, 2002 7:58 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Separate document for multipath - or part of BGP spec 


Curtis,

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

In addition to getting consensus we also need (at least) two implementations
of the text. Otherwise, we wouldn't be able to include it in the BGP base
spec. With this in mind I would appreciate if folks who implement something
along the lines of the text below drop me an e-mail.

Yakov.

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