[28164] in North American Network Operators' Group
Re: UBR at MAE-East ATM, anyone?
daemon@ATHENA.MIT.EDU (Richard Irving)
Tue Apr 18 13:11:25 2000
Message-ID: <38FC963D.14634A41@onecall.net>
Date: Tue, 18 Apr 2000 12:07:09 -0500
From: Richard Irving <rirving@onecall.net>
MIME-Version: 1.0
To: "Lauren F. Nowlin" <ren@onyx.net>
Cc: Steve Feldman <feldman@twincreeks.net>,
Alex Rubenstein <alex@nac.net>, nanog@merit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
Read on, Oh wise one.
"Lauren F. Nowlin" wrote:
>
> Thanks for your update Steve and to Alex for getting the ball rolling.
>
> ONYX would also like to see this change implemented.
>
> The model the AADS team uses is far superior to any other scheme to
> 'monitor' interactions between peers at the PVC level. Hands-off full mesh
> build is the easiest to activate rapidly without botched PVCs trickling in
> one-by-one or stuck in a random queue of a departed employee..
In a large corporation, individualistic details can get lost in
the broad scope of things. Rate Cap'ing is
wonderful thing, IMHO, as long as you have -adequate- resources to
respond to the individual granularity of the dynamics of the -real-
flows.
Ahhh... Therein lies the caveat, eh ?
:\
The best laid plans of mice and men......
> The
> PeerMaker method is too human intensive for little to no gain from an
> operational sense. A negative if you can't use the capacity for fear of
> artificial caps being exceeded with other peers, which is the case noted
> below.
Great minds..... :)
>
> Also, I've never understood why PBNAP PVC build requests between two
> customers - approved by both customers - have to be sent to PacBell
> Marketing for approval...
>
Didn't they, in the old days, need to clear "tarriffing rules" out
there ?
Dereg was young....and some states had differing (read complex) regs. I
know
we had a - mess - with it....
Just my .02
Richard
