In einer eMail vom 19.04.2008 00:33:08 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
> even the existing routing paradigms should be questioned. > LISP doesn't do anything for Multicast, it doesn't do anything wrt > the IPv4 depletion I have mentioned before that we are working on LISP-Multicast and indicated an Internet-Draft will be available by the end of April. We are still sticking to that schedule. And the main LISP spec describes two approaches that can be taken. The yet to be published draft-farinacci-lisp-multicast-00.txt chooses one of them and details the design. 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. > issue, it produces new update churn as to fight existing update churn. > Or: Wasn't IPv6 the future? Now the new routing architecture is > supposed to be backward compatible with IPv4 AND !!! IPv6. Hasn't > IPv6 got its chance and didn't it miss this chance ? > What about the orthogonality between intra- and interdomain routing > protocols?! Isn't this a pity ? > I mentioned Multicast and LISP above. I should defend LISP. All > existing multicast models have an enormous flaw: they are not state- > less. This can be changed and -imo- should be changed. Stateless-multicast can only mean that you broadcast traffic everywhere. ;-) 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 Dino > > Summary: There could be such a bright future for routing.But not if > BGP, i.e. the distance vector algorithm, is considered a holy cow. > > Heiner > > > In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit > schreibt [EMAIL PROTECTED]: > Hi, > > thanks for your note - it does really make things a lot clearer. > > On 2008-4-18, at 0:07, ext Lixia Zhang wrote: > > Further, once we have surveyed the solution space, we need to > > develop rough consensus on the approach through the solution space. > > Arguing about 'incremental deployment', for example, doesn't help > > this at all. We need to first come to some agreement on the very > > highest level branches in the decision tree (e.g., do we do map-and- > > encap or translation or ???), and not worry about the detailed > > leaves. That is up to the IETF to wrestle with. > > I hate to bring up the R-word, but I think before we can get to a > consensus on architectural or technical directions for a solution, we > need some consensus on what the requirements are for the architecture. > What are the goals and non-goals? > > All the solution proposals on the table apear to have slightly > different sets of problems they address, based on what the proponents > of each consider important. The ongoing discussion intermingles > arguments about which goals are important to address for a future > architecture with which technical mechanisms are suitable to address > them, and that's confusing (well, to me at least.) > > Lars > > -- > 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 >
