Subject: Re: An MP alternative

From: Vernon Schryver <[email-masked]>
Date: Tue, 7 Apr 1998 13:32:48 -0600 (MDT)

I'm confused.  If the MP header is removed and there is no fragmenting,
then why do any MP negotiating?  Given the relatively specialized,
specially configured, or known-to-be cooperating peers, what's the point
of MP negotiating?

If there is no MP header or fragmenting, then how is this MP alternative
different from what I've been calling 'BF&I multilink' for years, what
various vendors including Livingston and Silicon Graphics have been
shipping (and interoperating) for years, and what I understand to be what
the Linux community calls "load balancing"?

It must be that I've misunderstood.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Wed, 8 Apr 1998 09:03:47 -0400

> specially configured, or known-to-be cooperating peers, what's the point

Because the underlying MP negotiation mechanism provides a number of
worthwhile benefits:

	- It does negotiate, so changing versions of software at each
          end of the link, including going "back rev," should work,
          even if it causes a fall-back to multiple parallel network
          links exposed to routing software.

	- It pulls one more error-prone mechanism out of the equation.
          It is the case that load balanced links should all have the
          same MRU/MTU and that they should have the same network
          layer end-point addresses and options (if any).  MP provides
          a reasonable mechanism to validate these things.

	- MP checks for other potentially disasterous
          misconfigurations, such as a new pipe configured with the
          wrong peer.

> the Linux community calls "load balancing"?

It's not different.  Ross Callon and I had a conversation about
scaling the routing protocols and I mentioned to him that load
balancing would help greatly.  He noted that despite much industry
experience and common understanding, there was as yet no standard for
doing this.  To write a standard for it, I considered just codifying
BF&I in an RFC, but then I realized that to be complete, I'd have to
document what ought to be done with misconfigurations and other error
cases.  At that point, I'd be reinventing at least one half of MP.

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp