"Cisco MPLS-based VPNs" & BGP Stability

Mailman List Mirror (Read Only)
1

Not at all. Please provide data which would prove your "clearly"
statement. Second I would say if there is any impact this is only
implementation specific impact. In other words if your bgp
implementation does not separate different address family processing,
trie maintenance, allow for independent timers etc ... you may be right
but I am not aware of any such implementation deployed anywhere so far
:).

As a matter of fact a lot of today's mpls-vpn deployments use different
set of relflector's hardware for vpnv4 routes plus are using default
route for providing internet access for mpls-vpn customers so I don't
really see how those SPs/ISPs would impact with mpls-vpns any ipv4 bgp
Internet infrastructure or bgp stability. Total AF isolation can be also
easily achived even for inter-as mpls-vpns as well with correctly
architected design.

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. Or does the separation you refer to suggest that
we have no worries with BGP and route table growth, churn
frequency, et al., and that it should be left to the academics?

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.

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. Feedback especially regarding the "Security" document
I referenced. As well, I felt that feedback on potential impacts
to the global routing stability should be of relevance to the
community (versus swept under the rug).

-danny (who strives to only listen to the rest of this thread)

2

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. Or does the separation you refer to suggest that
we have no worries with BGP and route table growth, churn
frequency, et al., and that it should be left to the academics?

I don't believe anyone's suggesting that.

Full Internet routing tables, unicast IPv4 BGP peering over RFC2547(bis)
networks should be done between peers directly, and not with the PE (there's
really no reason for the PE to participate in this, all the PE needs is a path
to get to the CE and the other PE, and vice versa).

So, you do peer with (or import static from) each CE attached to a PE. Per
VPN, how many summarized routes are you going to get? a dozen? two dozen per
VPN tops? With the average being much less, right? So, a couple of thousand
VPNs add a couple of thousand or so more routes in the BGP (counting
everything as VPNv4 addresses) don't add all that much grief, or do they? Now,
keep in mind that again, all the PE-CE peering needs to pass is enough routes
for the CE-PE-PE-CE communications (and the various iterations with n peers)
to occur. If CE's peer with BGP, they would exchange routes directly with the
other CE in the VPN via eBGP multihop. Otherwise, it's whatever the IGP
summarizes and passes to the PE.

Maybe I'm missing something here, but that's how I see the world, and I'm not
sure this is such a big deal. The work we've done in this area in the past
confirms that.

It's a tool. And if you decide to blow one or both of your feet away, it's
your choice. But there's nothing that says that's the only way to use the
tool, or the only reasonable or least ops pain to use the tool.

Cheers,
Chris

3

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.

4

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

5

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.