Hey Chris, I'm not sure we're actually arguing against each other, but just to clarify... nothing wrong with enforcing a topology (or rather traffic flow) inside the SP cloud. Neccessary, and very much needed from the SPs standpoint. What makes up a topology is much more dimensional (IMHO) than just hub-and-spoke etc. So, instead of one blindly taking from customers (stubborn as they may be about it) a topology, rather than a service definition and build the most suitable topology based on that definition.. definition = "SLA"/"OLA" or other type of contract. Ideally (hah!), customers should care about how much data (if they even know quantitive measures of their traffic) from where to where, and which what characteristics (qualitative is almost equally tricky, but more achievable) by giving customers guides etc, without actually limiting them to chosing those slots. Seems once you monitor, whether you monitor in buckets or raw is more a marketing question that technical. In my experience, most customers know little or nothing about their actual needs. Once "trained" by the telcos to order in arbitrary categories such as 56DDS, T1, T3, OC-x, they sometimes don't even know they're using up all available capacity. Some don't even care. And a service offering has to match all. So, you should be able to have a "quick order VPN" as well as an "a la carte VPN". So, that's where a service provider should step in and provide guidance and counseling, since it is truely in both best interest. As one can see, though, this does very quickly transcend the technical domain. Either way, MPLS VPNs do permit both, defaulting on any one mechanism appears to be a disservice, IMHO. Interaction is what's needed, rather than engineering in a vacuum. Cheers, Chris PS: To me, hub and spoke with a single link to the hub is no longer true hub and spoke, because of the aggregation performed. Anyways, semantics, I suppose. -- Christian Kuhtz, Sr. Net & App Architect Architecture, BellSouth.net <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Atlanta, GA "Speaking for myself only."
-----Original Message----- From: Chase, Christopher J (Chris), ALNTK [mailto:chase@att.com] Sent: Monday, September 11, 2000 1:40 PM To: 'Christian Kuhtz'; 'mpls wg' Subject: RE: ISPs offering VPN service
Enforcing a topology within the provider portion of the VPN makes perfect sense, rather than expecting the VPN owner to enforce a topology.
Customers may not have the capability to implement or manage TE tunnels to enforce a topology on top of the any-to-any connectivity. In addition, that would require running MPLS to the CE instead of providing a VPN service that uses standard IP CE-PE interface (e.g., FR or PPP).
Examples of wanting other topologies: inter corporate extranets, network based firewall services, regional company gateways.
One big advantage of the MPLS VPN hub-and-spoke topology over the private-line/VC model is circuit aggregation. The hub or data center site only needs to terminate a single logical connection independent of the number of remote sites. I know a lot of large enterprise networks using the PVC hub-and-spoke model having to spread those PVCs across many ports and routers at the hub site.
Chris Chase AT&T IP Enabled FR Architect