Doesn't make what any less braindead ?
>It is trivially simple to determine the load on a sync line. ANY sync line.
>Just count how many flags are being sent (required to be transmitted any
time
>an HDLC line is not fully utilized) and if you're not getting ANY the line
>is at capacity.
BACP has absolutely *zero* to do with determining load.....
>You can self-calibrate this as well. Since you know how many flags you
>*can* get in a unit of time (due to the fact that you know how many bits per
>second the line is clocking and you also must know the HDLC requirements
>since you're DOING it), you can now set a percentage of utilization at which
>you consider the line "full" and which mandates a channel be added. This
>can then be externalized in the form of a parameter which says "at X%
>capacity, add a channel, and at Y% of combined capacity, drop one".
>Some basic sanity checks (ie: Y must be <= 1/2X to prevent constant
>oscillation) and you're done.
>
>Note that this works WITHOUT any BACP nonsense, and furthermore, it works
>regardless of whether you're the TRANSMITTER or RECEIVER of the data stream.
It does work irregardless of BACP or MP+....that's NOT what they exist for...
>Some folks, notably SGI, figured this one out *YEARS* ago in their ISDN
>connectivity implementations.
>
>I have brought this to the attention of ASCEND and several other vendors
>multiple times.
I'm confused by what point you're making here. BACP/MP+ are not
solutions for load calculation - never have been...
>ASCEND has ignored these facts for well over a year.
Tell me again what facts we are discussing...?
>Adding protocol layers on top of a system to perform a job which is
>trivially able to be accomplished without doing so is, in my opinion,
>braindead and shows a lack of operational thinking processes within the
>organization that does so. The only *other* possible argument for this
>behavior is to make it "harder" to cleanly interoperate with the maximum
>number of devices on the other side. That's a good reason NOT to buy
>or recommend such a vendor's products.
BACP has a reason for existing, that's why Ascend, Shiva, Cisco, Bay,
Microsoft and others got together to thrash out the details... are you
saying that all of these companies where wrong ?
>BACP has its place (notably in async environments where you *can't*
>determine how "full" the line is).
BACP has *nothing* to do with determining load!!!!
>This isn't one of them.
>
>To *ALL* the ISDN vendors out there -- do this one right. Its not difficult.
....Hmm.
Kevin Smith Updated Service and Support
Senior Technical Support Engineer Resources are now at:
Customer Satisfaction
Ascend Communications http://www.ascend.com/service