[128031] in North American Network Operators' Group
RE: "vpn exchange point"
daemon@ATHENA.MIT.EDU (Vitkovsky, Adam)
Fri Jul 23 07:36:56 2010
From: "Vitkovsky, Adam" <avitkovsky@emea.att.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Michael Dillon
<wavetossed@googlemail.com>
Date: Fri, 23 Jul 2010 13:36:06 +0200
In-Reply-To: <AANLkTikaSxL4m3FrJWzMz7uY8DsFop1P_JpSnhQ0JGsx@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Yes please I believe that what Michael have mentioned by the mpls NNI is ac=
tually the RFC 2547bis Option 10A
And yes please as Chris mentioned this Option 10A is used mainly between tw=
o 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 t=
here 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 s=
hortest path towards the destination PE/CE -the PE can't tell because it's =
missing the whole picture=20
The other two RFC 2547bis options: Option 10B and 10C requires some level o=
f trust between the autonomous systems and thus are rarely used between dif=
ferent 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 th=
e 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 10=
B and 10C
The other way to extend the reach of an ISP is the Carrier supporting Carri=
er 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 a=
ll 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=20
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 woul=
d 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=20
-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 exch=
ange routing information and traffic=20
-with important difference:
This "mpls-vpn-IXPs" would not be passing any actual traffic -just the rout=
ing and vpn information
Remember these are just RRs and do not need to or should not be on the forw=
arding 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)
=20
