Hi Dave,
It raises the question of whether or not you put your VPN's BGP routes on the same peering infrastructure that you use for your EF traffic.
First thx for your mail. Second reg your inter-as design let me explain a bit more what I meant by saying easily :). The most scalable soultion for inter-AS support of mpls-vpns you get by direct vpnv4 multihop sessions betwen peering ASs vpnv4 relfectors. So the vpnv4 prefix exchanges can be totally still separated from any ipv4 peerings. For this to work you need additionally: * exchange prefixes to your PEs next hops with labels between your ASs, * disable next hop insertion on the EBGP session from RRs. In this desgin you still don't need to have any intersection of vpnv4 and ipv4 routes.
Merging your isolated VPN environment with the Internet in any way could have
Well maybe with an exception that for a small number of VPNs merging global Internet table with MPLS-VPNs customers on the same PEs does not reduce your ipv4 stability at all. So if you accept this the financial aspect of building isolated l3 vpns while maintaining the same level of ipv4 characteristics can be easily achived by adding one or few (depending on the number of vpn customer's routes) RRs. R.
Dave Siegel wrote:
On Tue, Apr 17, 2001 at 02:04:48PM -0700, Robert Raszuk reportedly typed:
Danny,
which clearly impacts unicast stuff as well.
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.
Indeed, the VPN infrastructure is a TE overlay on your MPLS network, and the BGP information stays at the edge. This design does not, by itself, impact the BGP stability of your (EF) Internet product.
Total AF isolation can be also easily achived even for inter-as mpls-vpns as well with correctly architected design.
I wouldn't say "easily" acheived, but it does need to be correctly architected, especially an inter-provider MPLS VPN.
It raises the question of whether or not you put your VPN's BGP routes on the same peering infrastructure that you use for your EF traffic. In a purely theoretical world, perhaps this is trivial to establish QoS on network borders, and exchange routes for EF class (Internet) along with your AF (business/VPN), but this might not be so practical in reality, at least not today.
In a purely isolated design, VPN routers on the VPN overlay mesh would be designated as gateways to other providers, dedicated to AF, and dedicated to interconnecting with other providers for VPNs only. Designing this is pretty easy, but building this dedicated infrastructure for inter-provider VPN takes time, money, business cases, and new contract negotiations.
Merging your isolated VPN environment with the Internet in any way could have disasterous effects on your ability to deliver on AF traffic garantees, even with QoS enabled.
At least for now, "don't cross the streams."
Dave
R.
Danny McPherson wrote:
I thought this might be of interest to folks here, it looks strikingly similar to draft-behringer-mpls-security-00.txt, which has uni-directionally discussed on the IETF's PPVPN mailing list a while back.
I think a more pragmatic approach could have actually been useful, however, this would likely require a non-commissioned perspective. IMO, things like "Hiding the Service Provider Core Network" aren't very practical.
I'd also like to get feedback on how folks see things like MPLS/BGP VPNs impacting Internet route table stability and convergence. After all, simply because it's not necessarily envisioned (by some) to be deployed inter-domain, it does make heavy use of BGP, which clearly impacts unicast stuff as well.
-danny
------- Forwarded Message
Date: Tue, 17 Apr 2001 12:08:01 -0400 To: mpls-ops@mplsrc.com From: Christopher Lewis <chrlewis@cisco.com> Subject: Security on MPLS VPNs
The Mier group released a report that showed MPLS VPNs offer the same level of security that frame relay and ATM networks do. That report is available at http://www.mier.com/reports/cisco/MPLS-VPNs.pdf
- ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
------- End of Forwarded Message
-- Dave Siegel These opinions may not necessarily reflect that of my employer HOME 520-579-0450 dave at siegelie dot com WORK 520-572-9041 dsiegel at gblx dot net Director, Global IP Network Design, Global Crossing