Hi Christian, In message http://psg.com/lists/rrg/2007/msg00532.html you wrote about LISP proxy and NAT systems to provide connectivity from non-upgraded systems. I don't understand what a LISP "proxy" or NAT would entail in sufficient detail to comment further.
You also wrote: > Ivip avoids the dependency on a single proxy by grouping multiple > providers to do the proxying for redundancy. An edge network's > EID space is then advertised by multiple providers. Using the MAB (Mapped Address Block), UAB (User Address Block) and micronet terminology I proposed in: http://psg.com/lists/rrg/2007/msg00533.html http://psg.com/lists/rrg/2007/msg00535.html I would restate this as: Ivip avoids the dependency on a single ITR for handling packets from non-upgraded networks by having multiple providers run multiple ITRs to attract packets from non-upgraded networks and to tunnel those packets to the correct ETRs. This spreads the load, provides redundancy and generally reduces the path lengths. So an edge network's micronet is advertised in BGP by multiple ITRs of multiple providers, as part of a larger MAB (actually, an IMAB - Ivip Mapped Address Block). > To reduce the number of routing table entries, Ivip also groups > edge networks, and it uses one EID block per edge network group. I think you are describing how each MAB contains one or more UABs, each of which contains one or more micronets - and how the MAB has a single advertisement in BGP. > The Ivip model creates new dependencies, though: > > - Providers in a group are bound to other providers in the group. > They must coordinate their BGP advertisements because a customer > edge network of one provider is also a customer of the other > providers in the group. The Ivip proposal doesn't mention "groups" of ISPs. It is assumed that anyone who runs an ITR in "the core" (meaning it accepts packets from the BGP routers of other ISPs and end-user networks) does so in a way which is coordinated on a global basis, by making sure the ITR gets a reliable feed of mapping update information, and making it not advertise a MAB if it no longer has up-to-date mapping information for it. This is assuming there is a single Ivip system and all the ITRs in the core (those which advertise MABs and so attract packets from networks which have no ITRs, or just caching ITRCs, which can't handle all packets with destination addresses within a MAB) handle every MAB in the whole system. The current Ivip-arch-00 ID assumes that each ITRD (ITR with a full database, via a full feed of realtime updates) handles every MAB - although it would be possible to load-split between multiple ITRDs by having each ITRD advertise a subset of the total set of MABs. The ID also assumes that an ITRD has the full database for all the MAB it advertises. Another possibility, suggested by Bill Herrin, is that a particular ITR might have the full database (be an ITRD) for one or more MABs but be a caching ITRC for other MABs. This was also suggested, I think, by Noel Chiappa, regarding regions: http://psg.com/lists/rrg/2007/msg00492.html I haven't written about this, but I think any ITR which is only caching the mapping data for a particular MAB should not advertise this MAB. Caching ITRs (ITRCs) are good for tunnelling packets to ETRs when those packets are passing through them. However, an ITRC shouldn't pretend to be the destination for packets addressed to a particular MAB when it is only caching the mapping for that MAB - unless the ITRC has a reliable way of passing on the packets it has no mapping for to an ITRD. If an ITRC was advertising the MAB, it would need some private tunnel arrangement to an ITRD for this purpose, since it couldn't simply emit the packet - the packet would simply be attracted back to the same ITRC. > - Edge networks in a group are bound to other edge networks in > the group because they cannot leave the group without > renumbering. I would say that since a MAB (or at least an IMAB, as I define it) is a block of address space with the mapping controlled by a single body (Root Update Authorisation Server - RUAS - in Ivip), it follows that the end-user networks using the micronets in a single IMAB must all depend on this RUAS. Figure 4 at: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html shows a single RUAS receiving mapping update information from multiple other Update Authorisation Server (UAS) companies, each of which receives mapping updates from end-users, other UASes, or from multihoming monitoring systems appointed by the end-users. Each RUAS would control the mapping of one or more IMABs. The system need not be this complex. An RUAS could also deal with end-users directly, and run its own internal multihoming monitoring system which generates mapping updates. > - Edge networks are bound to their provider group because they > cannot move to a provider in a different group without > renumbering. I think what you are referring to as a provider group is in fact the RUAS which is authoritative for the mapping for the MAB which the end-user's network's address space is within. Without Ivip, there are two dependency scenarios: 1 - The end-user has PI space. They are not bound to any ISP - only to the RIR who gave them the PI space. These end-users can multihome, have portable address space etc. But each such end-user adds an advertisement to BGP for every division they make of their address space. In practice, with IPv4, the granularity of PI space divisions is 256 IP addresses. 2 - The end-user has no PI space, so they are bound to whatever single ISP they choose. They can't do multihoming (unless they use SHIM6 or Six-One) and the PA address space their ISP gives them is not portable. They can get as much or as little space as their ISP allows, without the 256 address granularity imposed by current (and probably persistent) IPv4 BGP practices. The good thing is these end-users don't add to the number of BGP advertisements. The bad thing is there are a growing number of these folks, they are not happy. If we don't invent a good multihoming and portability scheme, they will each want and probably get PI space and so add one or more advertisements to the global BGP routing table - seriously burdening every ISP. With Ivip (or probably the other ITR-ETR schemes if they worked well), there is a third state an end-user network can be in: 3 - The end-user gets some address space from some organisation X in a MAB for which the mapping information is controlled by a particular RUAS organisation Y. The end-user also chooses one or more ISPs with ETRs, which they depend upon at any one time, but are not bound to. They remain bound to organisation X and are also dependent on the particular RUAS. Perhaps X is an RIR, or an ISP. Perhaps the RUAS organisation Y is the same as X. Perhaps it is a specialist RUAS organisation or a domain name registry company. So this is a dependency basically on X, which either runs its own RUAS or chooses some other company Y to do so. A more complex set of dependencies would exist if the end-user got its address space from company C, which got it from B, which got it from A, which got it from X. In that case, the end-user needs to look behind C to find out who else they are becoming dependent upon. Of course, such complex arrangements are only going to exist if the relevant RIR allows address space to be used in this way. The end user can slice and dice their address space with complete freedom, including down to single IP addresses, each of which can be mapped to an ETR in any ISP the end-user chooses to use. As long as the relationship with X persists, the address space is multihomable and portable to any ISP which has an ETR. There is no extra burden on the BGP routing system by all this slicing and dicing, or changes to this. I don't think that the Ivip model necessarily involves dependencies much more problematic than those of an end-user with PI space. Since the RUAS X has no geographic limitations, and does not involve the end-user in any particular ISP or access network, the dependencies in Ivip are far less onerous than those of an end-user who has PA space at present. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
