In einer eMail vom 19.04.2008 00:33:08 Westeuropäische Normalzeit schreibt firstname.lastname@example.org:
> even the existing routing paradigms should be questioned.
this is a misunderstanding. Of course you will and can provide some draft which will outline how LISP will cope with the existing multicast models. No doubt.
My critic is that the architecture discussion isolates the diverse issues. That's why I mentioned Multicast and OSPF.
About 10 years ago I wrote to Scott Bradner "why we have Multicast addresses " that is comparable with "why do train cabins have compartments and not the seating arrangement like in an aircraft". It is obvious for reasons of tradition. The first train drew a couple of coaches, and IP adopted MC addresses from LAN. His response: your point is well taken.
However all the problems are interwoven. There is the IPv4 address depletion which appears to be most urgent. At the same time Multicast is wasting address space by more than a billion class D addresses although the same purpose could be accomplished (the identification of any multicast instance) by means of a new "Multicast forwarding" protocol type combined with the sender's Unicast IPv4 address + port. Such a change would relax the situation substantially at least for some more years.
Or, take OSPF. Why will OSPF never finish? Sure there will always be new node/link related stuff to be advertised. But can't all of it be completely opaque to OSPF?
But first of all OSPF itself is truely not yet completed: ipfrr can just be the beginning of enhanced intradomain routing. It has one valuable approach: After at least one Dijkstra best next hop is determined, it uses the idle time to improve its routing capability. BGP with/without LISP wastes the time with update churn processing. This is obviously due to the protocol. Proof: No such churn in OSPF.
Also, because OSPF and BGP are such different /orthogonal it isn't possible to do more sophisticated routing. OSPF-MT can never be extended to interdomain. There may further interesting objectives like "safest routing". It may be - politically- an even more interesting rerouting topic than the fast speed of ipfrr.
There are many more objectives, e.g. with respect to TE or Network Management, which aren't badly served by the current architecture.
Oh no. Just because all so far standardized multicast models do need state, that does not mean that there were no alternative.
Funny enough, you mention broadcast: There are also better methods than flooding for doinge broadcast. But certainly not without knowledge about the network topology.
There are well-known disadvantages of BGP. The most important one however is never mentioned: you have no topological view and therefore no view of that subnetwork which would use some particular (current) router for transit. How can you do better than TE guess work in such a situation ?
It is wellknown what RPF means. But it does not mean what it says: reverse path forwarding means forward to the upstream subtree (which may start out with several links).
In summary: Isolated handling of individual problems is not an architecture