Hello, Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end If there would be just a few autonomous systems involved I could do option-C and run a full mesh between the Inter-AS-RRs Let's also assume there are more Inter-AS-RRs per AS -but still with small number of ASes the full mesh is doable However if there's like dozen or more ASes -peering with all the Inter-AS-RRs would be cumbersome -that's where the vpn exchange point would be appropriate I believe the exchange-point could work something like option-c ---- Inter-AS-RR-AS1---- Inter-AS-RR-AS2---- Inter-AS-RR-AS3---- -where the AS2 would be represented by a single node -the exchange point Let's also assume the ASes have separate mpls links enabled between them Than this exchange point is just about the control plane (no transit traffic -just inter-as-vpn-routes distribution) It's like adding another layer of RRs to the picture Let's say there are Intra-AS-RRs -that reflect routes between PE routers within a single AS Let's say there are Inter-AS-RRs -that reflect routes between multiple ASes (but if there are may ASes and we can't cope with the full mesh anymore) We can ad Global-RRs --that will reflect routes between Inter-AS-RRs -these Global-RRs could be thought of as the exchange points adam
On Jul 21, 2010, at 9:13 AM, Vitkovsky, Adam wrote:
Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns
That would be like an IXP but for email. Or an IXP but for web traffic. VPNs are an application that run over IP, and IXPs are interconnection locations for IP traffic. So you don't need to worry about what you're worrying about. Nor, for instance, do the VoIP people. Ahem. -Bill
OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS. The question really is... does it make sense for carriers to create an MPLS/BGP VPN sort of internet? I'd vote probably not in their immediate interests. --WM On Wed, Jul 21, 2010 at 11:44 AM, Bill Woodcock <woody@pch.net> wrote:
On Jul 21, 2010, at 9:13 AM, Vitkovsky, Adam wrote:
Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns
That would be like an IXP but for email. Or an IXP but for web traffic. VPNs are an application that run over IP, and IXPs are interconnection locations for IP traffic. So you don't need to worry about what you're worrying about.
Nor, for instance, do the VoIP people. Ahem.
-Bill
On Jul 21, 2010, at 12:59 PM, William McCall wrote:
OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS.
Isn't that what one iteration of IXP-NSP in Japan was? I seem to recall that they talked about it a lot, back when MPLS was still trendy, but I haven't heard word one about it for many years since. -Bill
On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote:
On Jul 21, 2010, at 12:59 PM, William McCall wrote:
OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS.
Isn't that what one iteration of IXP-NSP in Japan was? I seem to recall that they talked about it a lot, back when MPLS was still trendy, but I haven't heard word one about it for many years since.
The TelX Video Exchange http://www.telx.com/Products-Services/telx-video-exchange.html is supposed to be a MPLS to MPLS exchange with some tailoring for H. 323 (and maybe SIP/RTP) video transport. Regards
-Bill
<cough>equinix ethernet exchange</cough> On Wed, Jul 21, 2010 at 10:59 PM, Marshall Eubanks <tme@americafree.tv> wrote:
On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote:
On Jul 21, 2010, at 12:59 PM, William McCall wrote:
OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS.
Isn't that what one iteration of IXP-NSP in Japan was? I seem to recall that they talked about it a lot, back when MPLS was still trendy, but I haven't heard word one about it for many years since.
The TelX Video Exchange
http://www.telx.com/Products-Services/telx-video-exchange.html
is supposed to be a MPLS to MPLS exchange with some tailoring for H.323 (and maybe SIP/RTP) video transport.
Regards
-Bill
Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns
Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end
In the MPLS world, this type of interconnect is called NNI (Network to Network Interconnect) and it needs to take into account things like COS mappings. I don't know of anyone doing this as an exchange, But I imagine that if you had a router with a private ASN, you could always do NNI with a different ASN on each port and therefore, achieve something analogous to an IXP. But you could only do this if you control all the ASNs involved, because vPn is a form of private network, so you need a higher level of trust with the other ASns. Most MPLS providers only use this to extend their reach into a territory where they will likely never build PoPs. For instance, to get good coverage of Russia, population 150 million, or the 4 Nordic countries, you could either build loss-leader PoPs, spend lots of money on longlining or do NNI with an MPLS provider that has good coverage because they focus on smaller regional customers. --Michael Dillon P.S. If you do this, it would be interesting to report back to NANOG on how you configured it, and what are the strengths and weaknesses.
On Thu, Jul 22, 2010 at 3:46 PM, Michael Dillon <wavetossed@googlemail.com> wrote:
Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns
Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end
In the MPLS world, this type of interconnect is called NNI (Network to Network Interconnect)
hey look frame-relay! (joking, sorta, not really) In almost all cases this is still done via the A version (or 1 version of 4) mpls interconnect types where each customer VPN is broken down to native-IP links (vlans most often I believe, sometimes frame dlcis! :)) and the contracted cos/qos setup is replicated on the adjacent provider's interface as well... as you (michael) pointed out though, it's pretty much only done for 'i dont want to build in XXX' places. Additionally, from my (admittedly limited involvement) understanding these sorts of connections are notoriously problematic, painful and ultimately expensive for the provider(s) in question :( boo.
and it needs to take into account things like COS mappings. I don't know of anyone doing this as an exchange, But I imagine that if you had a router with a private ASN, you could always do NNI with a different ASN on each port and therefore, achieve something analogous to an IXP.
the real question is why? what's the business driver? what's the support model? is it truly worthwhile? -chris
Yes please I believe that what Michael have mentioned by the mpls NNI is actually the RFC 2547bis Option 10A And yes please as Chris mentioned this Option 10A is used mainly between two different administrative domains (ISPs) because of the lack of trust and maybe a sort of configuration simplicity (known CE-to-PE setup)-despite of it's obvious drawbacks like the lack of scalability (because for each vpn there need's to be a sub-interface configured and the ASBRs need to hold all the vpn routes) The other drawback is not optimal routing across the AS regions/domains Yes the PE has an optimal route towards the ASBR -but is that ASBR on the shortest path towards the destination PE/CE -the PE can't tell because it's missing the whole picture The other two RFC 2547bis options: Option 10B and 10C requires some level of trust between the autonomous systems and thus are rarely used between different ISPs -though these options found a great use in ISPs with more than one AS# -where advertising the ip addresses of PEs and Inter-AS-RRs into the different AS (as in option 10C)-is not a concern Both Option 10B and 10C provides end-to-end LSP necessary for mpls services (like TE,VPLS,..)-in addition to that Option 10C provides optimal routing across the AS domains -these might be couple of business reasons for opt 10B and 10C The other way to extend the reach of an ISP is the Carrier supporting Carrier model but that's a whole another playground :) Now back to my initial assumptions Should a provider have multiple AS numbers (for whatever reason: supporting different regions, fusing with other ISPs) -assuming common control over all the ASes -that provider's best choice would be to use Option 10C for the reasons mentioned above However the Option 10C has one drawback -it does not scale well should the number of AS regions increase Should we want the full view from all the PE routers -we would need a full mesh between the Inter-AS-RRs -which are exchanging the vpn routes between AS domains and forwarding them to the PEs in their local AS afterwards -we could mitigate the issue of full mesh requirement between RRs by using the RR-Clusters and just do a full mesh between the clusters (which I didn't lab yet and I'm not sure how the cluster configuration would interact with the vpnv4 RRs) Or the other solution is to introduce another level of RRs into the picture of full mesh between the Inter-AS-RRs In this solution the Inter-AS-RRs would not peer with each other in a full mesh fashion -but they would rather peer with the higher level RRs "Global RRs" avoiding the need for a full mesh (I didn't lab this one either so I'm not sure how it will work out) These higher level RRs "Global RRs" would be sort of a "mpls-vpn-IXPs" As with well known IXPs they are deployed where a lot of ASes needs to exchange routing information and traffic -with important difference: This "mpls-vpn-IXPs" would not be passing any actual traffic -just the routing and vpn information Remember these are just RRs and do not need to or should not be on the forwarding path -we are only talking control plane here And I'm assuming the AS regions are interconnected via links between ASBRs in each particular AS -with no global visibility (data plane)
If you are going to go multi-VLAN data plane (as opposed to multi-label) then 10A will cause you scaling issues as you'll need multiple BGP peers (or static routing), I'd prefer to use http://tools.ietf.org/html/draft-kulmala-l3vpn-interas-option-d-02 which already has implementations, i.e (albeit differently named) http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_opta... Dave.
Yes please -option d also known as option AB -it's the same as option b with addition of VRFs on the ASBRs -it might as well be viewed as a natural step between opt a and opt b -opt ab offers the same great control over the routes advertised between ASes as opt a -though provides for better scalability by introducing mp-ebgp session between ASBRs By removing the VRFs from the ASBRs and turning off the default mp-ibgp behavior -option b doesn't suffer from some of the inherent drawbacks of opt ab like: Increased memory demands because ASBRs have to store routes in the per-vrf RIBs in addition to mp-bgp database Opt b has also streamlined the forwarding process by omitting the additional per-vrf ip lookup on the ASBRs The tradeoff is however -less control over the routes advertised between the AS domains One advantage that comes naturally with opt ab is -you don't need to worry about the import/export RTs not matching in two different ASes and configuring RT rewrites on ASBRs -opt ab will take care of that for you adam -----Original Message----- From: David Freedman [mailto:david.freedman@uk.clara.net] Sent: Friday, July 23, 2010 5:21 PM To: Vitkovsky, Adam Cc: Christopher Morrow; Michael Dillon; nanog@nanog.org Subject: Re: "vpn exchange point" If you are going to go multi-VLAN data plane (as opposed to multi-label) then 10A will cause you scaling issues as you'll need multiple BGP peers (or static routing), I'd prefer to use http://tools.ietf.org/html/draft-kulmala-l3vpn-interas-option-d-02 which already has implementations, i.e (albeit differently named) http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_opta... Dave.
On Fri, Jul 23, 2010 at 9:45 AM, Vitkovsky, Adam <avitkovsky@emea.att.com>wrote:
Yes please -option d also known as option AB -it's the same as option b with addition of VRFs on the ASBRs -it might as well be viewed as a natural step between opt a and opt b
-opt ab offers the same great control over the routes advertised between ASes as opt a -though provides for better scalability by introducing mp-ebgp session between ASBRs
By removing the VRFs from the ASBRs and turning off the default mp-ibgp behavior -option b doesn't suffer from some of the inherent drawbacks of opt ab like: Increased memory demands because ASBRs have to store routes in the per-vrf RIBs in addition to mp-bgp database Opt b has also streamlined the forwarding process by omitting the additional per-vrf ip lookup on the ASBRs The tradeoff is however -less control over the routes advertised between the AS domains
One advantage that comes naturally with opt ab is -you don't need to worry about the import/export RTs not matching in two different ASes and configuring RT rewrites on ASBRs -opt ab will take care of that for you
FWIW - I tried to get a couple of larger carriers in the states to do option b with my company (we are an ASP) - where we were the other 'ISP/AS'. Doing so would have allowed me to extend the VRF / VPN-ipV4 addresses to my core and map those to a VLAN interface in the same VRF (thus allowing all of our customers to maintain their own IP ranges instead of us handing out non-overlapping ranges). None of them would do it for security / manageability reasons. The solution today is back to back DS3 with frame encapsulation and a gazillion sub-interfaces (each sub-interface is in a VRF - and each VRF can have a VLAN interface for L2 and L3 autonomy). It solves my problem - but the config is a little complicated. So for me - it'd be nice if the carriers played in the Multi-AS backbone arena a little more. I could loose frame encapsulation and the management/scalability issues that goes along with a ton of sub-if's. It'd be easier on their provisioning teams as well. Not to mention a simplified QoS config etc... Another practical use for multi-as MPLS VPN options: if there were 2 providers that used RFC 4364 Multi-AS options - I could provide carrier / circuit redundancy into my data centers. Today I can only do that via a single MPLS provider and hope the core engineers of that carrier don't make mistakes...If I could have an MPLS circuit dropped from 2 different providers that provide access between our customers and our data centers - there'd be a lot of value there. I'm sure a lot of enterprises using MPLS would be interested. Kenny
participants (8)
-
Bill Woodcock -
Christopher Morrow -
David Freedman -
Kenny Sallee -
Marshall Eubanks -
Michael Dillon -
Vitkovsky, Adam -
William McCall