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)
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 -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm BellSouth Internet Services, Atlanta, GA, U.S. Sr. Architect, Engineering & Architecture "I speak for myself only"
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.
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. ---------------------------------------------------------------
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. ---------------------------------------------------------------
participants (4)
-
Christian Kuhtz -
Danny McPherson -
Franklin Lian -
Robert Raszuk