"vpn exchange point"

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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

5

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

6

<cough>equinix ethernet exchange</cough>

7

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.

8

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 :frowning: 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

9

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 :slight_smile:

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)

10

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_optab.html

Dave.

11

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

12

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