|
In einer eMail vom 19.04.2008 00:33:08 Westeuropäische Normalzeit schreibt
dino@cisco.com:
> even the existing routing paradigms should be questioned. Dino,
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
Heiner
|