Hi Randall, Thanks for your replies. You wrote:
> Most of your stated beliefs here about "reality" are inconsistent > with my own prior experience in Network Engineering for a > multi-continent ISP, inconsistent with my prior work on a very > large all-continents private IP network, and inconsistent with > my experience in enterprise IP networks. > > It is perhaps not surprising that since my experience > is so inconsistent with your assertions, then I don't reach > the same conclusions that you have reached. OK. > Given the charter at hand, which is for the Routing RG to > propose an architecture to the IETF rather than to endorse > some specific engineering proposal, it is not at all surprising > to me that the Routing RG has followed its charter and has > not focused on trying to select a specific engineering proposal. I understand this. In order to arrive at that architecture some questions are being asked, such as whether or not to consider translation schemes. In order to come to a reliable answer about that, or any other decision to include or exclude a class of potential solutions, I think it is necessary to look at at any detailed proposals in that class. Other people may think a decision can be made reliably without considering such low-level details. In one of my messages I do discuss a translation approach to the routing scaling problem in a purely theoretical manner (without reference to Six/One Router) and argue that this class of solution can only be useful with multiple sets of address space - which is not feasible with IPv4. > More generally, I'd encourage you to try to raise the "altitude" > of your discussions -- less about specific detailed proposals, less > about *engineering* tradeoffs (both of which are IETF responsibility, > not IRTF responsibility), and more focus about the *architectural* > tradeoffs to hand. In my view the path to the best design involves a lot of work with low level details - trying one combination and then another, trying to find a set which works really well together. I am not rushing into implementation, as the LISP folks seem keen to do. I am considering low-level details such as PMTUD: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ that every map-encap scheme needs to consider. Fred Templin is the other person who has tackled this difficult area in meaningful detail. So far, the LISP team have only a cursory and I think inadequate approach to PMTUD, and there is nothing in APT or TRRP which considers it. One could design a building in sweeps of aesthetic and broad functional design, and leave the details to engineers to sort out. However the best buildings are achieved by simultaneously considering many lower-level aspects of the design, such as exactly where the air is going to flow, where the services are going to be installed and maintained, where the light is going to fall at various times of the day and year, how noise from the airconditioning affects those inside and outside the building etc. I have a proposal to solve the routing scaling problem, and as far as I know, you don't. I would really appreciate you and others criticising my proposal. While there is a lot more work to do on it, some key parts of it are described in enough detail for you to critique it in meaningful detail: http://www.firstpr.com.au/ip/ivip/ http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip-arch-01 http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 Some people prefer to operate from a high altitude. I try to consider all levels at once. - Robin -- 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
