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

[Russ White <[e-mail]>]

Agreed--let's leave this out of scope, and see about a seperate
draft.

Russ

On Fri, 18 Oct 2002, Natale, Jonathan wrote:

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

__________________________________
[e-mail] CCIE <>< Grace Alone