Subject: Re: BAP Negotiation - Link Types

From: Vernon Schryver <[email-masked]>
Date: Mon, 22 Jun 1998 09:06:09 -0600 (MDT)

> Ummm...  Why do you need definitions for leased lines?  BAP is used
> for dynamically adding/dropping links.  That sort of implies
> dialed/switched lines, doesn't it?

A better question is, given L2TP why you need (or care about) BAP at all.

Since the last time I made my "BAP/BACP/MPPP/MP+ is snake oil" rant, I've
been playing with a Cisco box that talks to some Ascend boxes, both
supporting BAP/BACP/MPPP/MP+.  I've been unable to detect any effective
difference with BAP/BACP/MPPP/MP+ enable or disabled.  I figured that
given the opportunity, I should at least check my claims.

BAP/BACP is theoretically useful for allowing two or more boxes in a single
hunt-group and that do not support L2TP to act as a single box, but useless
for any other purpose.  If you have two or more boxes that need to answer
MP calls and the boxes don't support L2TP, then it is generally necessary
to cause the peers to dial the same box that their first phone call
reached.  That implies the boxes need to communicate the phone numbers of
reserved ports.  The second-link phone numbers must be reserved and not
in the main hunt-group, since otherwise the probability that each box will
have available ports is too low.  That almost everyone who is willing
reserve 30-50% of their ports to is also or more willing to put each box
into its own hunt group is one reason why BAP/BACP is in practice
essentially never used for this purpose.  That there are literaly millions
of PPP "clients" that support MP but not BAP/BACP is another compelling
reason for not relying on BAP/BACP for the second port phone number.
Another consideration is that a major reason for starting L2TP was to
eliminate the need for PPP "clients" to know anything about the number of
boxes composing the "server", including not needing any new PPP protocol
support.

There were and are no other valid technical justifications for BAP/BACP.
One bogus but frequently made claim was that "servers" can measure the
link load but "clients" cannot.   As now demonstrated by zillions
commercial PPP products, that was silly.  As long as the MP bundle contains
at least one link, each of a pair of PPP peers can compute the loading of
their link in both directions.  That means that having a PPP "server" tell
the "client" what the client already knows, whether their link is
saturated, is useless.  BAP/BACP was intended to run on "servers" typically
operated by internet service providers, providing service that is billed
to those running "clients."  Who would willingly delegate the decisions
on when to add another link to an MP bundle (e.g. at 10% or 100%s
staturation) to the outfit that makes up the bills?  No one would trust
an ISP to never "accidentally" set the add-a-link threshold to 10%, except
when an additional link is free, and then they'd not trust the ISP to not
set the threshold at infinity instead of 0%.  Everyone wants their own
clients to count bits and make the add-link decisions.  That implies the
facilities in BAP/BACP/MPPP/MP+ for the "server" telling the "client" to
add a link are uninteresting.

BAP/BACP/MPPP/MP+ cannot help with communicating the bundle utilization
during the only time when the "client" does not already know it, when
there are no links in the bundle.  BAP/BACP/MPPP/MP+ also does not help
with phone numbers when you need such help the most, when you cannot get
the first link up.

In the last couple of years, there has been talk that BAP/BACP/MPPP/MP+
is needed to support D-channel data, on the grounds that "clients" cannot
figure out that they are sending or receiving close to 16 kbps and so need
to add a B channel.  Of course, the talk is never phrased that way, since
it makes the reasoning sound rather weak.

Early in the days of BAP as distinct from BACP/MPPP/MP+, it was suggested
that PPP "servers" would use BAP to tell "clients" whether they have
permission to add another link.  In the real world, such facilities are
not used or implemented that way.  Instead, higher priority is given to
"bosses" (one suggested catagory) by using different phone numbers.  Peons
or customers with low priority service dial additional lines regardless
of whether the "server" says yea or nay.  All reasonable "client"
implementations do the obvious right things when phone calls for additional
links in an MP bundle don't work, regardless of what BAP/BACP/MPPP/MP+
has or has not said.

Vernon Schryver    [email-masked]