The MPLS-OPS Archive

[Vic Nowoslawski <vnowoslawski@mac.com>]

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. 
>######################################################################################################

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