In einer eMail vom 04.06.2010 19:31:32 Westeuropäische Sommerzeit schreibt [email protected]:
On 4 June 2010 at 16:41:15 Tony Li sent: > > > But RRG's charter includes exploration of "addressing" problems. > > An "address" is used to determine forwarding operation. > > So it's natural to discuss forwarding issues here. Right? > > > Ummm... No, not in the full generality of how some people use that term. > > Again, we were chartered to discuss routing and addressing architecture. > Forwarding issues typically involve interesting questions about how you can > structure your FIB to minimize painful memory accesses, what type of memory > to use, how it should be interconnected to your processing element, how to > deal with ECMP, dealing with indirect next hops and the like. All of those > are out of scope. > > Regards, > Tony > > > OK, I agree. Tony, however I do disagree. You just looked at what rtgwg is doing (ECMP, "via"-routes ) and concluded such topics belong to rtgwg, hence not to RRG, hence is out of scope. First:the IAB-report talks a lot about Moore's law. Second: A routing architecture is more than just solving the scalability problem. Obviously you only look backwards: LISP is (as said by their authors themselves) a jackup solution. ILNP revitalizes ideas which exist at least for one decade (right? btw this is not a disadvantage per se. But it is nothing new under the sun; it is still the wrong way of understanding hierarchy ) A routing architecture is more. It should concurrently serve all the important issues: -scalability (of course) -mobility, multihoming,TE forward (knowing multipath alternatives) and backward (figuring out to choose the right multipath alternative) e.g. for the sake of traffic balancing or the sake of congestion handling. -multicast ( I don't know what is more disappointing: the IETF multicast technology or the fact that multicast is a non-issue in the RRG). By addressing one issue after the other you will get any arbitrary solution in the end which is cast by the sequence these issues have been addressed. (btw, this is my general observation wrt to all IETF progresses, too) Heiner Heiner But there is one certain point of intersection of addressing, forwarding and path selection: As clear an address shows a node's topological location, that much it facilitates hop by hop path selection to that node, says: decision making for forwarding, sequentially. So why not just embed next hops in an address: locator? _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
