From: MADMAN (dmadlan@qwest.com)
Date: Tue May 11 2004 - 15:09:01 GMT-3
Howard C. Berkowitz wrote:
>>>
>>> In certain, restricted, cases, usually requiring gigabit or faster 
>>> transmision media, yes. See such things as Private VLAN Service (more 
>>> the IETF term) and QinQ encapsulation (although the latter is not a 
>>> WAN protocol, but the distinction between LAN and WAN is less and 
>>> less useful).  It's also possible using MPLS.
>>
>>
>>   Not that restricted actually and on speeds as low as 100M.
> 
> 
> /* begin Hindenburg news announcement voice
>   "Oh, the humanity!"
> /* end announcer voice
> 
> Do remember, Sir, that you are speaking to one whose first interactive 
> terminal ran at 110 bps.  100 Mbps. Slow. (makes noises about 
> impetuosity of youth, then goes into hysterical giggles).
> 
> Seriously, I've dealt with the desire to have LANs-across-wide-areas [0] 
> for several years, and I still think that while it will work in some 
> restricted cases, it's a system collapse waiting to happen.
> 
> Broadcasts and multicasts are a significant issue.  If the topology is 
> simply straight-line, I suppose you can just pass the multicast 
> addresses and not worry about replication. That gets more complex in a 
> branching tree topology that stil is perfectly valid under spanning 
> tree, but where you will HAVE to have a replication function, or at 
> least nontrivial forwarding logic that looks inside the tunnels [1], to 
> handle multicasts at branching nodes.
> 
> While host processor speeds have improved, you still remain vulnerable 
> to broadcast storms.
   Absolutely but there are plenty of networks that have no more than 
100M links that work fine.  You have to look at each case individually, 
I would not suggest any partciular speed fits all cases.
   But hey we are in the bandwidth business, the more the merrrier!!
   Dave
> 
> Remember, too, when extending what is essentially an L2 service, you 
> lose many of the standard tools such as ping, traceroute, and possible 
> ARP cache checks. Yes, Cisco is coming up with L2 traceroute 
> equivalents, but this is not a trivial problem.
> 
> [0] Let me emphasize my concern is with end-to-end use. Using 802.1q over
>     dark fiber or even WDM, with a QoS-enabled L2 switch at the customer
>     premises connected to the POP is perfectly reasonanle.  One can then
>     map VLANs to VPNs, and use (G)MPLS in the core. Again, there is L3
>     intelligence in such a system.
> 
> [1] 802.1q over dark fiber, or even WDM, isn't necessarily tunneled.
>     If your scaling technique is QinQ, or other things like L2TP, carrier-
>     scale equipment may have to look awfully deeply into the frame.
> 
>> We are rolling out a new service that will provide this using 6500s in 
>> the core and 3550's at the customer site, MPLS is also being used.  
>> The customer can route, trunk or whatever they desire.
>>
>>   Dave
> 
> 
> I know customers _want_ it.
> 
> At 2AM last night, I _wanted_ ice cream. I wasn't dressed, my car wasn't 
> working, and I'm a diabetic.
> 
>>
>>>
>>> Why do you consider this a good idea?  It has potential scalability 
>>> issues, for example, involving both absolute delay greater than 
>>> expected by LAN devices.  Another scalability issue is that 
>>> uncontrolled growth at both locations may cause the safe number of 
>>> devices in a broadcast domain to be exceeded.
>>>
>>> I've been asked to do this many times, on the basis that "layer 2 is 
>>> simpler."  At a certain level of scaling, it is not. In general, in 
>>> the circumstance you describe, I'd route between the sites without 
>>> overwhelming evidence to the contrary. I can even keep VLAN numbers 
>>> consistent at both sites.
>>>
>>> Unfortunately, studying for the CCIE lab overempasizes lots of things 
>>> that may be possible, but not a good idea in the real world.
>>>
> \\
> 
-- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367"Emotion should reflect reason not guide it"
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:09 GMT-3