Hello Heiner, The short version of this message is:
Your proposal requires host and router changes - so it is not a solution to the current problems. If you create a comprehensive description of it, with low-level router behavior specifications and detailed examples, I will check it out. You wrote, in part: > LISP nor is it my intention. Just the opposite: With the rejected > NIRA project and no further proposal submission opportunity for > the next years on this area, I should be glad if all are > concentrated on the loc/ID split protocols in the meantime. That is what I am working on. > Constructive criticism: I cannot provide such, e.g. for CONS, if > I am convinced that all of it is not needed at all. This seems to contradict your previous sentence, unless you are happy for us all to work on something you are convinced is not needed. > Anectodal accounts: I do not precisely know what you mean, ... > I did provide a lengthy description of my NIRA concept a week > ago. Your description: http://psg.com/lists/rrg/2007/msg00523.html had no mention of how routers were to behave in order to achieve the objectives you described. I think this is a short, incomplete, description of even your objectives, with over-reliance on a postal analogy. By the way, I think the postal redirection analogy is a very powerful one for explaining ITR-ETR schemes - in particular the scaling problems of every Post Office sorting office having the full database and performing a lookup on every destination address. I use it myself. > It was much better than what we submitted to the EU. I am not surprised that, as you wrote on 7 November, your submission was "rated to be POOR and therefore rejected." > I know for sure that it will work, Many new architectures might "work". The question is, which one would work best - for a given deployment timeframe and a given set of restrictions regarding incremental deployability. In the next next 5 to 10 years, I think this means no host changes and as few router changes as possible. (This statement will probably always be true - I don't know how any scheme, no matter how promising, could prompt enough people to make the serious investment of host changes, new routers etc. if the benefits only accrue 5 or more years later.) > but I have to presume that the > geographical coordinates of the packet destination can be > provided by DNS as an additional information, and that this > information can be written as an optional parameter into the IP > header. But if I see how often AOL-software or Windows-software > upgrades are urged to be installed, I hope that this can be done, > too. I do not share your or Tony's optimism about how much we can rely on host upgrades. I discussed my concerns yesterday: http://psg.com/lists/rrg/2007/msg00559.html You can't rely on new things in the IPv4 header unless you require every router in the world to be upgraded to suit your new system - because changing the IP header requires complete router upgrades and using an option header causes many, most or all current DFZ routers to process the packet very slowly. Bill Herrin had a promising scheme which relied on option headers: http://bill.herrin.us/network/trrp-via02.html but such use of option headers turns out to be unworkable, as was discovered by Brian Carpenter 13 years ago with his AEIOU proposal: http://psg.com/lists/rrg/2007/msg00350.html Since your proposal is a long-term one, involving host changes, and new protocols - a new IP header or new option header - with major upgrades or replacements to all routers, I will not devote much attention to it. If you create a comprehensive description of it, with low-level router behavior specifications and detailed examples, I will check it out. - 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
