Subject: Re: issue 11

From: Curtis Villamizar <[email-masked]>
Date: Tue, 01 Oct 2002 14:18:57 -0400

In message <[email-masked]>, Alex Zinin writes:
> Curtis,
> 
>  I disagree here. In routing, node-local decisions affecting the
>  routing and forwarding tables are as important as the algorithms
>  describing inter-node routing proto packet exchange. From this
>  perspective, multipath definitely belongs in the spec.
> 
> Alex

I think it would be better off in another document because unlike OSPF
multipath:

  1.  You can go outside the AS and therefore cause huge differences
      in delay over the N available paths.  In OSPF the path delays
      differences are not as great although you can still mess up TCP.

  2.  We'd have to put in wording to forbid per packet multipath
      (there is an RFC on the pitfalls of doing a naive multipath
      implementation by Dave Thaler and Chris Hopps, RFC-2991).

  3.  If we mention BGP multipath and we don't forbid multipath which
      causes massive out of order delivery, then naive vendors are
      bound to implement it in the "considered harmful" way.

I think this one belongs in a separate draft but if you insist, we
have to do an adequate job of covering multipath since some forms of
it are harmful.  We should at least reference RFC-2991, include strong
wording about reordering and use of RFC-2991 techniques (src/dst
modulo-n-hash being the current favorite) to avoid it, and put limits
on what is and is not a reasonable place to put the "cost is equal"
decision in the route selection (it must be after IGP cost, step "e"
in 9.1.2.2).

Curtis

> Monday, September 30, 2002, 8:49:17 AM, Curtis Villamizar wrote:
> [...]
> > Alex,
> 
> > Multipath does not meet the criteria we have previously stated for
> > adding something bases on the existance of implementations that
> > support it.  That criteria was that the added feature was nearly
> > universally implemented and deployed among the major parties and that
> > implementing it or not affected interoperability.
> 
> >   1.  Regardless of whether a particular router has BGP multipath
> >       enabled or disabled, its external behaviour from the standpoint
> >       of BGP protocol interaction is completely indistinguishable.
> 
> >   2.  In the decision process, after IGP cost is considered, some
> >       (most) routers are capable of considering BGP routes of equal
> >       cost for the purpose of forwarding and capable of putting more
> >       than one forwarding entry (typically a small integer number of
> >       entries) in the FIB.  This is entirely a local matter.
> 
> >   3.  The only external sign that BGP multipath is enabled is that
> >       packets are forwarded differently, but still loop free.
> 
> > Therefore this feature in particular does not belong in the base spec
> > and there is no need to even mention it.
> 
> > Curtis