The MPLS-OPS Archive

[jim guichard <jguichar@cisco.com>]

Karl,

At 08:25 21/09/2001 -0700, Karl Garcia wrote:

>I don't want to get into trouble for plugging CoSine here

then don't :)

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

that is a pretty blanket statement - please try to keep marketing hype off 
of the list and lets concentrate on technology .. Jim

>   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>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>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>http://www.mplsrc.com/mplsops.shtml 
>
> > >Archive:
> > 
> <<http://www.mplsrc.com/mpls-ops_archive.shtml>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 
 > >http://www.mplsrc.com/mplsops.shtml
> >Archive:
> ><<http://www.mplsrc.com/mpls-ops_archive.shtml>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. 
>######################################################################################################



Jim Guichard CCIE #2069
Technical Leader
IOS Technology Division
MPLS & IP Routing Technologies

+44 208 756 8806
Mobile: +44 7802 809763

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