Re: "Cisco MPLS-based VPNs" & BGP Stability

[Robert Raszuk <raszuk () cisco com>]

Hello Franklin,

I promised to Danny to stay silent but since there are a few things I
must clarify in your mail I will break my promise with just one small
calrification:

> as OSPF that is widely deployed in enterprise network.  With pure VPN
> I can try to reduce the BGP timer for speeding the convergence up,
> however, with full Internet routing table I would not do that.
>
> I will say the scalability and fast speed convergence is a pair of
> contradictions here.  Internet requires scalability much more, and
> enterprise network requires faster convergence time on the hand.  So
> I will not say it makes a lot of sense to bind them together.

Yes you are right. That is why all knobs we have are address family
specific. You can adjust timers for Internet routes in a different way
then for VPN one without impacting one with the other on the same
router.

R.

> Franklin Lian wrote:
>
> Hi, Robert
>
> After dealing with MPLS-VPN for about two years I have something to
> say about whether we should put IPv4 and VPNv4 on the same box.  Well
> I will be more focus on the enterprise side instead of Internet side.
>
> The characteristics of VPN are quite different from the Internet
> customers, and I don't believe it is a good idea to use the same
> hardware/software to address the requirements from two total
> different worlds.
>
> Here are some differences:
>
> Requirements            Internet                Enterprise
> ------------------------------------------------------------
> Access Speed            High (DS3 and above)    Low (64K~DS3)
> Routing table           Huge (100K and above)   Small (up to 10K)
> Serurity                Some                    Critical
> Convergence time        in term of min          in term of sec
>
> Regarding routing process, I have less concern on the impact that
> VPNv4 routes bring to IPv4, however, I have some concerns on the
> impact that the 100k IPv4 routes bring to the VPN world.
>
> Cisco IOS gives me two BGP timers for tuning the convergence time of
> BGP.  BGP has been proven to be scalable but not as fast as IGP such
> as OSPF that is widely deployed in enterprise network.  With pure VPN
> I can try to reduce the BGP timer for speeding the convergence up,
> however, with full Internet routing table I would not do that.
>
> I will say the scalability and fast speed convergence is a pair of
> contradictions here.  Internet requires scalability much more, and
> enterprise network requires faster convergence time on the hand.  So
> I will not say it makes a lot of sense to bind them together.
>
> Another issue is about maintenance and supporting.  Due to different
> access speed requirements, and technologies used for the services,
> the best IOS code for Internet service is not the code for the VPN
> service.  At least YET.  I understand theoretically the code can be
> converged into one, but I am talking about practical implementation.
> > From this perspective, does it make more sense to split the functions
> (IPv4 and VPNv4) into two sets of edge boxes considering the risks
> of hardware/software failure?
>
> The last point I would like to talk about security issue. Whenever
> an enterpirse customer put a RFP, security is always one of
> the most critical issue there.  When I answer my customer about the
> security I always say my MPLS VPN solution is as secure as FR/ATM
> solution because MPLS VPN technology can safely separate VPNs by
> deploying the address family and my service network is a private
> network that is not aware of the Internet at all.  However, I don't
> think I can guarantee the security level the same as FR/ATM if I
> combine the Internet and Intranet together on the same network.
> How can I prove that MPLS VPN solution is secured, or at least be
> competitive to FR/ATM VPN and IPSec VPN in term of security, when
> the underlay network infrastruction is directly exposed to the
> Internet?
>
> IMHO, technically I don't think it is a good idea to have one box
> supporting both Internet and MPLS VPN.  However, I do comprise to
> the idea for the cost reason.
>
> Franklin
>
> Robert Raszuk wrote:
> > Hi Danny,
> >
> > > I'm referring more to the PE impact, or any other router that
> > > participates in unicast IPv4 peering.  There's still a single
> > > BGP process, a finite amount of memory and CPU resources, etc..,
> > > and impacting any of these can adversely effect IPv4 route
> > > stability.
> >
> > But that was my point if you have a few vpnvs hang on any given PE with
> > a few thousand of routes I don't think even ipv4 peering PE will fell
> > any impact. On the other hand when your number of vpnv4 routes grow on
> > PE it is clear that with current hardware limitations (mostly memory, a
> > bit of CPU) operator will need to decomposition ipv4 nodes from vpn PEs
> > hence the PEs will have 0 impact to the ipv4 BGP stability.
> >
> > > I fully agree that if dedicated infrastructure is employed for
> > > this purpose then there will clearly be less impact.  However,
> > > the whole pitch is that existing network elements can be used
> > > to offer the service, the same network elements that provide
> > > "Internet" connectivity today -- and lots of folks have drank
> > > the kool-aide -- all in hopes of generating more revenue from
> > > their existing IP infrastructure, not new dedicated or overlay
> > > ones.
> >
> > As I said above you don't until you need to dedicate boxes for
> > mpls-vpns. When you have so many customers that don't simply fit into PE
> > (already loaded with 90K of ipv4 routes) you have two choices:
> >
> > A) Buy a more powerfull box,
> > B) Decomposition Internet and VPN
> >
> > > Then every time someone brings up a scalability or convergence
> > > or security issue with BGP/MPLS VPNs a slew of Cisco folks tell
> > > them it's targeted at private networks and different
> > > infrastructures (hence the requirement for BGP, MPLS, etc..,
> > > I guess).
> > >
> > > Rob, I know how you & your cohorts feel, I was looking for operator
> > > feedback.
> >
> > No it is not that I am feeling one way or the other. Getting feedback is
> > extremely usefull - but all I care about it to get feedback regarding
> > true issues not those which are practically not the problem.
> >
> > > -danny (who strives to only listen to the rest of this thread)
> >
> > I will do the same letting other's comment.
> >
> > R.
>
> --
> ---------------------------------------------------------------
> Franklin Lian (Lian, Zidan)          Global One
> Principal Engineer                   Mailstop: VAOAKM0201
> Email: Franklin.Lian () Globalone net   13775 McLearen Road
> Tel: (703)375-7893                   Oak Hill, VA 20171
> Fax: (703)471-3380                   U.S.A.
> ---------------------------------------------------------------