Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 30 Sep 2002 12:10:25 -0400

Curtis:
See below

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 11:49 AM
> To: Alex Zinin
> Cc: Yakov Rekhter; [email-masked]
> Subject: Re: issue 11 
> 
> 
> 
> In message <[email-masked]>, Alex Zinin writes:
> > Yakov,
> > 
> >   If we default to putting things in different drafts, we'll have a
> >   bunch of separate docs describing a single protocol. Multipath is
> >   something that is normally in the heart of a routing 
> protocol. There
> >   should be a good reason to want something like this in a separate
> >   document. Do we have one in this case?
> >   Thanks.
> > 
> > -- 
> > Alex
> 
> 
> 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.
> 
    As a peer to a router that has multipath routing enabled, I would like
    to know that this route has a twin sister route when making my decision
    on whether to pick this route in my decision process. If I did not I
    would bet the farm on a inconsistent route (implying the AS-PATH and
other
    attributes are not always used by this route-prefix. 
    
    I disagree on this point.

    As a personnal opinion, a smart peer should stay away from Multi-path 
    routes if all rules are equal with other non-multipath routes. 
    Reasons explained in 3 below.

>   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.
> 
  If packets from the same source and destination are forwarded differently
  via different Next Hops, intermittently, does'nt this opens such problems
  as sequence errors and non-deterministics forwarding behaviors. Creating 
  more confusion and latency problems at the end points? I realize this is
  a forwarding issue, but BGP is creating the issue for forwarding
  to solve.

  Because there are potential issues with multipath routing. We either add
  a dedicated section for multipath, or leave it out for now as Yakov  
  suggested.

Ben

> Therefore this feature in particular does not belong in the base spec
> and there is no need to even mention it.
> 
> Curtis
> 
> 
> > Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> > > Alex,
> > 
> > >> Jeff, et al
> > >> 
> > >>  I'm a little lost here. Considering that BGP multipath:
> > >> 
> > >>   - is implemented by at least two (major) vendors
> > >> 
> > >>   - affects core protocol mechanisms
> > >> 
> > >>   - is important enough to be thoroughly described
> > >>     to avoid implementation bugs
> > >> 
> > >>  why would we not want it in the base spec?
> > 
> > > Why not in a separate draft ?
> > 
> > > After all, there are quite a few *optional* BGP features that are
> > > implemented by multiple vendors, affect core protocol mechanisms,
> > > and are important enough to be thoroughly described to avoid
> > > implementation bugs, and are not in the base spec, but are in
> > > separate RFCs.
> > 
> > > Yakov.
> > 
> > >>     
> > >> -- 
> > >> Alex
> > >> 
> > >> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda 
> Ramnath - CTD, Chenn
> > ai.
> > >  wrote:
> > >> >> % The Loc-RIB SHOULD contain only one route per destination.
> > >> >> % An implementation may choose to install multiple routes to
> > >> >> % a destination (for the purposes of load balancing).
> > >> >> % An implementation doing this MUST ensure that it is
> > >> >> % interoperable with versions that do not, and MUST
> > >> >> % ensure that no routing loops or inconsistent routing
> > >> >> % information is propagated as result of this action. The
> > >> >> % handling of such a configuration, however, is outside the
> > >> >> % scope of this RFC.
> > >> >> 
> > >> >>    It does seem a little too detailed, though!
> > >> 
> > >> > My concern is not that this is rope to allow operators 
> to hang themselve
> > s
> > >> > with - this is a gatling gun that allows implementers to try to
> > >> > guess at useful rules and hose the Internet.  BGP, as 
> a protocol,
> > >> > is already prone to long-lived loops.  Lets not make 
> it easier to
> > >> > do this in a way thats harder to troubleshoot.
> > >> 
> > >> > I haven't thought about this in large amounts of 
> detail, but some
> > >> > quick observations on what could be done to actually implement
> > >> > this:
> > >> 
> > >> > o The routes should be equally preferable - i.e. they 
> need to enter
> > >> >   the tie-breaking process.
> > >> > o They should have the same AS_PATH
> > >> > o Perhaps the path attributes should only be allowed 
> to differ on
> > >> >   NEXT_HOP.
> > >> 
> > >> > *If* the above are true, then re-announcing any of the 
> routes used
> > >> > in the load-balancing should work fine as long as the 
> re-announcement
> > >> > is going to be a first-party nexthop.  If you have a 
> third-party
> > >> > nexthop, then you might end up with inconsistant forwarding.
> > >> 
> > >> > I would propose that this might be something worth 
> investing some
> > >> > time over, but it shouldn't be mentioned in the base spec.
> > >> 
> > >> >> Sivanand
> > >> 
> > >> 
> > 
> > 
> > 
>

---

From: Mathew Richardson <[email-masked]>
Date: Mon, 30 Sep 2002 12:56:39 -0400

> Abarbanel, Benjamin <[email-masked]> [Mon, Sep 30, 2002 at 12:10:25PM -0400]:
>Curtis:
>See below
>
>Ben
>

<snip>

You may wish to know that, but the protocol _as deployed_ provides
no means for that information to be conveyed.  If you call up your
peer, and find that they are, indeed, using multipath, then you
can make the appropriate policy decision; however, such decisions
can't be made based on information contained within the protocol.

<snip>

>  a forwarding issue, but BGP is creating the issue for forwarding

<snip>

As currently written, and deployed, the BGP protocol is not creating this
problem.  Rather, nonstandard extensions to the base spec are (potentially)
creating this problem.

>  a dedicated section for multipath, or leave it out for now as Yakov  

I'm for leaving it out now, and forever.  If we wish to document it,
it should be in a new draft.

<snip>

mrr

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 13:11:20 -0400

In message <[email-masked]>, 
>     Reasons explained in 3 below.

That is not how multipath works.  The same tie breaking takes place
and advertisements are indistinguishable even though the forwarding
entry is slightly different.

Please confine the dicsussion to how multipath currently works, not
how you would like it to work if we could change it.

>   a forwarding issue, but BGP is creating the issue for forwarding

This has been discussed extensively for longer than BGP-4 has existed.
It has been discussed over and over again in OSPF, IDR, and MPLS lists
and certainly in other WGs.

[FYI - there are multiple way to do multipath, some that work well and
most that don't.  Common are, per packet, per some other attribute, or
per a hash on src/dst.  Per packet is terrible for performance.
Src/dst hash works fine.  If there are N ways to go, just hash the
src/dst and modulo N and pick that interface.  Any given src/dst pair
always takes the same next hop.]

All routers either do src/dst hashing or the ISP (with any clue at
all) will turn off the feature and voice angry words with their router
vendor.

>   a dedicated section for multipath, or leave it out for now as Yakov  

I'll take choice two.  We should leave it out.

So we are in agreement after all, but for different reasons.

Lets end this thread now.

Curtis