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
Danny,
which clearly impacts unicast stuff as well.
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.
R.
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.