[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] NIRA:Combining the hier. interdomain and the OSPF-intradomain netwo...
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 rrg-request@psg.com 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