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)
