Frame Relay encap vis-a-vis point-to-point at UUNET

Vijay Gill wrath at cs.umbc.edu
Tue Sep 22 18:32:12 UTC 1998


On Mon, 21 Sep 1998, Dan Jones wrote:

> 	However, the statement 'would not suffer any bandwidth loss from
> using f/r encap' is largely dependent on the overbooking of those
> aggregation ports.  If it were me, I would a) make sure that 'full CIR'
> meant line speed & b)  want an assurance that the aggregation ports were
> >= the sum of all line speeds mapped to them.  Otherwise, one could very
> well argue that those connections are not pt-pt at all but FR clouds
> collapsed onto an on-site FR switch. 
> 
> 	If there is any overbooking going on on those aggregation
> connections, you are not getting your T1's worth and might as well have
> bought a FR connection in the first place. 

 The point where the congestion and overbooking takes place might be
anywhere along the source/destination pair.  Assuming provider A was
aggregating customers directly onto CT3 cards instead of frame relay
switches.  

The customer is now happy with his "point to point link."  Now, further
assuming the uplink from the customer aggregation equipment, to the
backbone transist system is worth X Mbps, then directly terminating a
number of connections onto the gateway with an aggregate _peak_ bandwidth
of greater than X Mbps just moves the choke point up further, to the
transist <--> Customer aggregation equipment link. This can be moved up to
any point in the network.

This is where aggresive monitoring and proactive retermination and/or
addition of more resources come in.

--
Vijay Gill                         |The (paying) customer is always right.
wrath at cs.umbc.edu, vijay at umbc.edu  |                  - Piercarlo Grandi
http://www.gl.umbc.edu/~vijay      | Eagles may soar, but weasels don't get
These are my opinions only.        | sucked into jet engines.




More information about the NANOG mailing list