Do MPLS service providers peer with each other over an NNI?
Probably this doesn't make much sense for IPVPNs because it would imply that the service providers would have to share the customers private addressing schemes
But what about if the traffic carried over the MPLS is using public addressing?
Yes, it is possible, although I don't know how common it is (at least in the US).
There are three mechanisms for enabling the NNI. In technical literature, these are named Option A, Option B, and Option C.
Option A (Back to Back) - The providers use logical identifiers, typically VLANs, to ensure separation. On each side, the VLAN is placed into a VRF. A BGP session is needed for all VPNs. This isn't a very scalable solution.
Option B (Multiprotocol BGP for VPNv4/VPNv6) - The providers establish a MP-eBGP sessions between them to exchange VPNv4 and/or VPNv6 prefixes.
Option C (MP-BGP + Label) - The providers establish a multihop MP-eBGP session between route reflectors. Labeled IPv4/IPv6 prefixes are exchanged so that end-to-end label switched paths (LSP) can be establish.
For a technical deep-dive, see Huawei's A Brief Study on Inter-AS MPLS at http://www.huawei.com/products/datacomm/catalog.do?id=1495.
Regarding your point about public addressing - MPLS/VPNs deliver packets with private (RFC1918) addresses or public addresses. Most companies use RFC1918 space but this isn't a requirement.
Short answer: Customer routes are neither known nor required for much of the network. For the points where they are known they are uniquely identified on a per customer basis. MPLS carriers (and individual private MPLS networks) do peer with one another, although that peering is much more ad-hoc than traditional IP BGP peering.
Long answer:
1.) Customer addressing is irrelevant because after the PE/LER the carrier network only sees the labels on the packet. In fact, the packet itself doesn't even need to be IP - some significant portion of labeled traffic carries L2 bridging. This is the "multiprotocol" part of MPLS. One of the traditional design goals for MPLS carriers was the so-called "BGP-free core" - as P / LSR routers would literally need no knowledge of any addressing apart from how to switch labels from one interface to another, thus reducing the amount of network state actually carried in the core from potentially many hundreds of thousands to a few thousand.
2.) Within a typical MPLS network two labels are applied to a given packet - inner and outer. The outer label is what's used by the network to make forwarding decisions as the packet passes through the network. At each hop the label is evaluated, matched against a path defined earlier, the label is swapped with another and the packet is forwarded. This path is known as an LSP (label switched path) and can be configured in a number of ways. This is also the mechanism by which traffic engineering is accomplished (i.e. steering certain kinds of traffic by criteria other than a simple shortest path). The result of the LSP setup process is part of the routing tables maintained amongst the PE/LER boxes via multiprotocol BGP.
3a.) While two labels are typical, more labels can be applied to achieve other functions. In some cases an additional label may be present to help define more granular QoS policies (rare) or, in other cases, a third label can be applied when carrier networks are connected to one another. This situation is known as carrier-serving-carrier (CsC) where a large carrier might provide transit to a smaller carrier. Imagine carrier A operates primarily in a region in the continental US while carrier B has an international presence. Carrier A's customer wants to add a site in Hong Kong but carrier A does not want to extend its network all the way to HK for one customer. A may contract with B to carry its labeled frames (...from what would probably be the closest equivalent to an NNI) via a third label which would then be stripped when it was handed off to A's devices in HK - which would then strip the remaining labels upon arriving at the egress PE. This is most equivalent to a wholesale transit agreement.
3b.) In addition to the option of additional label imposition two carriers might set up a whole series of non-labeled connections which correspond to particular customer networks. As mentioned above, this might be a series of physical links (expensive), VLAN's or even PVC's on a F/R or ATM circuit. The best analogy here would be that the customer network exists independently in the two MPLS clouds apart from a point where the two are joined as traditional networks (i.e. no actual MPLS involved in the peering). This sort of gateway is probably the most typical, as it can mirror traditional peering infrastructure in useful ways.
3c.) It's possible for the carriers to actually share label space - allowing LSP's to be signaled across one another's networks. This requires the sharing of multiprotocol BGP routing information and, possibly, protocols for LSP setup (i.e. RSVP). This implies a great deal of information shared between the two providers. This probably most applicable when one carrier purchases another and wants to integrate networks.
3d.) The outer labels used by the LSP's described earlier are generally dynamically determined and are only locally significant (i.e. the label ID on one link can be the same as a number of others elsewhere in the network with no ill effect). It is possible, however, for these labels to manually defined. Two carriers may agree upon one or more common statically defined labels and then essentially pin them to interfaces that directly connect with an external entity. This is fairly labor intensive but is absolutely in use.
4.) The L3VPN service (RFC2547bis) calls for PE / LER devices to peer with one another via iBGP and that IP routing information from the customer be tagged in a specific manner so as to be uniquely identified. The PE / LER appends what is known as a route discriminator (RD) to each customer route. The RD is a 64-bit value that contains information about this customer and the particular edge router bringing traffic in. One common syntax is a customer's globally assigned ASN followed by a serial designator. The result is that the routes as shared between the PE/LER's are actually 96-bit (RD followed by IP prefix). This assures that -all- routes received from the customer (even duplicates to be used for load balancing) are preserved and in no way have any effect upon either other customers or the infrastructure itself.
