I listened to the Friday morning meeting via a 64kbps MP3 stream - and didn't notice any glitches whatsoever. This is a modest, commonplace, consumerish, data rate - completely uneventful, across the planet in 17 hops from Oregon to Melbourne, Australia.
An ITR-ETR scheme with real-time (a few seconds ideally) push distribution of mapping data only needs 12 bytes for each mapping change, for IPv4: 4 bytes Micronet start address 4 bytes Length 4 bytes ETR address Length would compress well, since in virtually all updates the upper 16 bits would be zero. There's no need for lists of alternative ETRs or for ITRs to decide between them. This is assuming that the ITRs are not required to follow instructions regarding load splitting - ie. that the desired TE can be done by having some IP addresses mapped to ETR-A and others to ETR-B etc. 12 bytes is all we need for IPv4. IPv6 requires 32 bytes: 8 bytes Micronet start (bits 127 to 64) 8 bytes Length (bits 127 to 64) 16 bytes ETR address but it will be a long time, if ever, before IPv6 is highly utilized - and by then bandwidth, RAM etc. will be even cheaper. Lets ignore protocol overhead for a moment. There needs to be authentication, error detection etc. Also some management guff and flags to say the following updates are all for IPv4 traffic with IPv4 ETRs. Also, I will ignore the likelihood that each full database ITRD and QSD probably needs to get two separate streams of data for robustness. 64kbps = 8k bytes = 666 updates a second = 20 billion a year. Lets say we get to 100,000,000 multihomed end-user networks and each has, on average, two micronets. This is 200,000,000 micronets with an average change rate of 2 a week. The BGP system today, with ~240,000 prefixes, gives a router about 3 updates a second: http://bgpupdates.potaroo.net/instability/bgpupd.html but quite a bit of this is convergence towards a final state. I think it is fair to say that the actual change of advertisements, including those caused directly by outages, is half, a third or less of this rate. I don't see why the ITR-ETR proposals other than Ivip are based entirely on the belief that it is impractical or undesirable to fan out mapping changes to a few hundred thousand or a million ITRDs and Query Servers (QSDs). Even if they all had to stream across the globe like my MP3 packets travelled, I don't see it as so scary as to be unthinkable. Bandwidth, RAM and CPU power are cheap. Distributing mapping in real time might involve several tree-like structures, similar to multicast (maybe actual multicast, over a tunneled overlay network), with each ITRD or QSD receiving (ideally) two streams from different trees so the chance of packet loss is minimised. If a packet is not delivered, it can be requested from one of several servers run by whoever created that packet (whoever runs one or more Mapped Address Blocks). By the time we get to this 100 million micronet stage, bandwidth, RAM and CPU power will be cheaper still. Planning and building an ITR-ETR scheme like this is non-trivial, but it can be fast, efficient and robust - because it doesn't involve routers chattering to their peers, spreading information across the Net like rumours propagating through a crowd. I don't see what is so scary about real-time control of the global ITR system. The advantages are obvious - simplicity for ITRs, simpler mapping data, modular user control of mapping (multihoming service restoration detection and logic as they choose, not all built into a monolithic system) - and a whole new gutsy, efficient, approach to mobility which doesn't require host changes and which works fine with IPv4 and IPv6 alike. I see a huge amount of activity with LISP based on the fervent belief that we can't and never will be able to do real time push for this growing stream of 12 byte update messages. First there was LISP-CONS - a mess of new stuff to create a global scale query server system. It was clearly going to be slow, complex and costly. Now it is superseded. LISP-NERD is a "push" system, but with each ITR asking for updates from one of multiple relatively centralised servers. At least there is no packet delays or dropping. But there isn't a concept of a multicast-like replication system to fan the data out efficiently. Nor is there the concept (as far as I recall) of caching ITRs and local query servers. LISP-NERD is to be left on the back-burner, in favour of ALT. eFIT-APT has even slower aspirations for distributing the data globally, but has some smart (I think) arrangements for local full-database Query Servers (Default Mappers) which are also ITRDs - so most of the traffic is handled by caching ITRCs. Now (according to what I heard in the meeting), APT is to be merged with, or adapted to, LISP. TRRP relies on a global DNS-like query network. I think this would be simpler faster and more robust than CONS or ALT. However it is still too slow for realtime control and the simplifications and modularity this enables. I figure Bill Herrin will be busy for a while with democrats.org . LISP-ALT sounds nifty, but there are all sorts of delays in the paths taken across the world in this global query server system too. One level of aggregation may be a router in the the USA, the next in Japan, the next in the Netherlands. The query packets traverse the long tunnels between these routers, and have to make it all the way back along the same tunnels. There's no clear way of authenticating the ETRs which are the authoritative query servers for particular micronets, so the whole ALT overlay network needs to be tied together carefully, manually, according to business relationships. That makes it expensive to administer and costly to change. Yet when the customer decides on a new ISP, they need to change the IP address and the administrator of their ETRs. So this seems to defeat the purpose of ending provider lock-in. (Ivip uses username and password access, with a simple, lasting business relationship to the organisation which runs whichever Mapped Address Block the micronet is part of. See RRG message 536.) LISP is a complex mess of stuff and the IDs are now longer than Ivip's. Ivip isn't finished, but it has a clear vision and is a lot better explained than LISP. There are no contradictory, incompatible, variants - one cast aside after the other - as with LISP. Since its inception in mid-June, Ivip has had a plan for reachability from non-upgraded networks. LISP finally adopted the same system ("Anycast ITRs in the core" AKA "Proxy Tunnel Routers") in late November. APT doesn't have such a scheme and TRRP's deployment plans uses the word "stick" and "carrot" frequently. Ivip is the only ITR-ETR proposal to recognise that PMTUD problems need to be solved. I understand from the meeting today that the LISP folks are of the view that there is no problem. I would like to see their reasons for this. It would be nice if these problems could be ignored, while still allowing for deep and flexible placement of ITRs and ETRs. My IPTM proposal looks pretty good to me for the current situation of typically ~1500 byte MTU hosts and data links. However, it has problems when most hosts and most links are jumboframe compatible, but we still need to assume ~1500 PMTUs between ITRs and ETRs. Then, Fred Templin's critiques start to bite and his sprite-mtu proposal starts to look better. But sprite-mtu tends to assume that most hosts will implement RFC 4821 - and I think this is unlikely to occur any time soon, if ever. I think Ivip or some other scheme with real-time, simple, mapping data distribution is clearly the way forward - and the whole LISP effort will be of little lasting value. Alternatively, if LISP is built, many people would soon start ripping it apart in order to speed it up and achieve the simplicity, modularity and mobility support that Ivip aspired to from the start. - Robin http://www.firstpr.com.au/ip/ivip/ -- 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
