Resent for dispatching a spelling mistake primarily :-) In einer eMail vom 18.07.2009 23:33:32 Westeuropäische Normalzeit schreibt [email protected]:
In einer eMail vom 18.07.2009 17:10:05 Westeuropäische Normalzeit schreibt [email protected]: > Lixia Zhang wrote: > ... >> But I would like to step up a level and repeat what I said earlier: >> 1/ I do not think it is in our charter to define how many >> identifiers we ought to have, or what they ought to be. >> 2/ Our job is to figureout scalable routing architecture. >> 3/ We need to have a good understanding about the interplay between >> addresses and identifiers, no less and also no more. IMHO, at first it takes a clear idea about an architecture, i.e. about network components and how they should interrelate. These network components need to be identified, of course. However I don't think that it is helpful to define identifiers in the first place and then look for an architecture which complies with these identifiers. With MAC + IPv4 address we have 10 octets. Are they used best ? Why is there no co-working with IEEE such that the best exploitation can be made from having 10 octets altogether ? LISP needs an aditional header. I can anticipate that on day soon a second LISP-header is prepended to the LISP-header. My experience: if there is no discipline and no strive for optimal utilization, but egoistic behavior instead, then even more available octets won't help (like MAC+IPv6 =22 octets). Some email mentioned that the architecture should not just solve one particular problem (scalability) but should enable more flexible and better routing: - Is everyone happy with the existing Multicast solutions ??? - Is everyone satisfied by having no rear mirror for recognizing all those routers which would use the current one for transit? And by never being able to add one (e.g. for the sake of TE traffic balancing etc.) - Is everyone convinced that the orthogonality of intra and inter-domain routing is the best ever after ? Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
