The MPLS-OPS Archive

[Shane Amante <shane@amante.org>]

Tim -

On Sun, Mar 18, 2001 at 12:44:53PM -0600, Tim A. Irwin wrote:
> >> ...sure.  But is IPSec at the CE more scalable than MPLS VPN at the
> >> PE?
> 
> >As far as the SP is concerned, absolutely!
> 
> How is this obvious or scalable???

Obvious + scalable because all the SP needs to worry about is
transport of _vanilla_ IP packets -- something they already do.


> First of all your assuming that any type
> of CPE a SP's customer wants to use supports IPsec, which is not at all
> true.

Hmm, false.  Every business customer attached to the Internet has a
firewall.  Most general-purpose CPU firewalls are capable of handling
a reasonable encryption load -- in general, all can support at least a
T1 (1.544Mbps) worth of throughput of IPSec encryption/decryption.
Thus, there is no "added" cost in doing IPSec for most customers.
'Course, if you want higher speeds there is an incremental cost for
daughtercards for their existing firewalls to attain higher encryption
throughput.


> Secondly, IPsec has a very limiting factor in scalability - the
> encryption/decryption "tax".

See above.


> Third, IPsec makes it very difficult for a SP
> to assist a customer in troubleshooting problems since the SP intermediate
> devices can't see what's going on inside the IPsec ESP payload.

With IPSec there is no reason for an SP to **ever** see "what's going
on inside the IPSec ESP payload".  That would defeat the whole point
of the confidentiality and integrity of payload data provided by ESP.
It's just IP packets to the SP.  If the SP can't deliver IP packets
from edge-to-edge, then they've got big problems.  :-)


> Correct me if I'm wrong, but the customer is still sending and receiving
> "standard IP packets".  What do they care if I use spit and string as long
> as their business requirements and SLAs are met?

If you're accounting for true[0] confidentiality and integrity of data
as part of some customer's business requirements, then I'm OK with
that statement.

-shane

[0]: not "Ships in the Night" VPNs as provided by MPLS, rather
encryption + authentication of payload data.

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml