The MPLS-OPS Archive

[Karl Garcia <Karl.Garcia@cosinecom.com>]

Title: RE: nat at the PE

I don't want to get into trouble for plugging CoSine here, but I will point
out that CoSine switches are intelligent edge devices and do much more than
just IPSec.  We have full support for RFC 2547bis, and I think our implementation
is the most scalable out there.  If subscribers do their own encryption, then
that's great, but as Bob Staats pointed out previously, there is still functionality
that needs to be done at the PE.

The real question here is how to provide the service that subscribers want/need most
efficiently.
________
Karl

Karl Garcia
Sr. Mrkt. Engr.
CoSine Communications
Redwood City, CA

-----Original Message-----
From: Vic Nowoslawski [mailto:vnowoslawski@mac.com]
Sent: Friday, September 21, 2001 9:35 AM
To: Karl Garcia; 'Wulf Losee'; alfred zhang; mpls-ops@mplsrc.com
Subject: RE: nat at the PE

The only problem with providing IPSec in the Core of your network is the
cost and the very Liability of providing the service. Most people use their
own encryption end-to-end.

The concepts like CoSine's have long expoded.

At 10:40 PM 9/20/2001 -0700, Karl Garcia wrote:

>Wulf,
>
>In the old way of thinking, the customers network would end at the
>CE.  However,
>Service Providers are discovering that bandwidth is being commoditized and
>their
>margins are being squeezed.  Adding IP Services to the data streams passing
>through their networks is how many Service Providers are responding.  As a
>group
>these are often called networked-based IP Services.  NAT is one, firewall
>and IPSec
>are other common ones.  In order to do these effectively you need routing
>-- RIP,
>OSPF, IS-IS, BGP4, etc.  Essentially, the edge of the Subscriber network
>is pushed
>into the Service Provider's premise.
>
>In this scenario, MPLS VPNs are another (albeit cost effective) way of
>transporting
>subscriber data from one side of the Service Provider core to the other.
>
>So, yes the Service Providers are doing more work, but they are getting
>more revenue
>for providing these (managed) services.
>
>Hope this helps explain some of their motivations....
>_________
>Karl
>
>Karl Garcia
>Sr. Mrkt. Engr.
>CoSine Communications
>Redwood City, CA  94065
>
>-----Original Message-----
>From: Wulf Losee [<mailto:wulf@cisco.com>mailto:wulf@cisco.com]
>Sent: Thursday, September 20, 2001 5:49 PM
>To: alfred zhang; mpls-ops@mplsrc.com
>Subject: Re: nat at the PE
>
>Alfred:
>Why would you want to do NAT on a PE? From a customer's operational
>standpoint the CE is where customer's physical network ends -- and most
>customers like to have control of their IP space. From a service provider's
>operational standpoint, would they really want NAT sucking down the CPU
>cycles on their PE routers? -- which in turn would up their costs for
>providing MPLS VPN services their customers. Maybe I'm missing something
>here, but I don't see any reason in your CUG example that you'd need to
>have NAT on the PE routers.
>
>Please note: although I work for Cisco, I'm not advocating any Cisco
>position on this. I'm just trying to understand the technical and/or
>operational reason why you'd ever want NAT on the PE routers.
>
>--Wulf
>
>At 04:24 PM 9/19/2001 +0800, alfred zhang wrote:
> >Hi guys,
> >
> >   I'm doing some testing about nat in the mpls vpn .I assumed the ISP
> > want to provide internet access to their VPN customers only, with Closed
> > User Group, there can be a public ip address segment that every VPN can
> > access it. Due to IP address issue, NAT is needed somewhere in this
> > public segment for each VPN. Can PE do this nat function?Or I have to use
> > CE or one external NAT box.
> >
> >
> >Best regards,
> >alfred zhang
> >-------
> >The MPLS-OPS Mailing List
> >Subscribe/Unsubscribe:
> <http://www.mplsrc.com/mplsops.shtml>http://www.mplsrc.com/mplsops.shtml
> >Archive:
> <http://www.mplsrc.com/mpls-ops_archive.shtml>http://www.mplsrc.com/mpls-ops_archive.shtml
>
>
>********************************************************
>"They that can give up essential liberty to obtain a little temporary
>safety deserve neither liberty nor safety." - Benjamin Franklin, ~1784
>********************************************************
>Wulf Losee
>Product Manager
>Cisco Systems, INSMBU
>email: wulf@cisco.com
>vox: 408.525.1493     cell: 408.406.4914
>fax: 408.525.4251     page: 800.365.4578
>********************************************************
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:
><http://www.mplsrc.com/mplsops.shtml>http://www.mplsrc.com/mplsops.shtml
>Archive:
><http://www.mplsrc.com/mpls-ops_archive.shtml>http://www.mplsrc.com/mpls-ops_archive.shtml
>
>######################################################################################################
>This email communication may contain CONFIDENTIAL INFORMATION and is
>intended only for the use of the intended recipients identified above.  If
>you are not the intended recipient of this communication, you must not
>use, disclose, distribute, copy or print this email. If you have received
>this communication in error, please immediately notify the sender by reply
>email, delete the communication and destroy all copies.
>######################################################################################################
###################################################################################################### This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above.  If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ######################################################################################################