From: Scott F. Robohn (sfr@xxxxxxxx)
Date: Thu Jun 01 2000 - 00:41:40 GMT-3
Jeff,
Some thoughts on this:
(1) If you have a service that uses SVCs (e.g., map-lists
w/NSAP addresses, CLIP, or LANE), it's alot easier to
provide any-to-any/'virtual full-mesh' connectivity. It
take a little work up front to build the services
(ATMARPServer, LES, etc.), but once they're built, adding
clients is relatively easy. Try building a full-mesh
between 50 or 100 nodes with PVCs. Yuck!
(2) Dynamic mechanisms like the ATMARPServer or the LES
avoid problems with statically defined mappings.
(3) LANE is admittedly complex, especially now that you have
ISL and 802.1q trunking. LANE was designed and standardized
under the assumption that 'routers are slow' and the only
remotely standards-based VLAN trunking mechanism was the
FDDI 802.10 SAID hack. So it was a step in the right
direction way back then. Today, routers are much faster, we
have trunking mechanisms that allow you to keep your traffic
in frames (no cellification or complex services). So LANE
isn't exactly taking off in terms of new implementations.
(4) You'll see LANE mostly in enterprise networks, and some
of those networks spreading ELANs across WAN links. PVCs,
PVPs, SPVCs, and SPVPs are pretty popular for service
providers and will likely exist for some time.
HTH,
Scott
Jeff Sapiro wrote:
>
> My only experience with ATM is at a large ISP that
> used PVC spokes for it's customers. I'm studying the
> configs for SVC's, CLIP, and LANE, and I don't see the
> advantage of using these, other than dynamic address
> resolution. LANE seems particularly complex for this
> small piece of functionality. Anybody have real world
> examples of where these approaches are more
> appropriate than PVC's? It would really help my
> understanding of the configs.
> -Jeff
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:32 GMT-3