RE: ISPs offering VPN service

["Christian Kuhtz" <ck () arch bellsouth net>]

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