Short version: Responding to Joel, with a change to the first
paragraph.
Hi Joel,
You wrote:
> This long list of "goals" has the interesting property that each of them
> sounds reasonable, but each is phrased in such a way as to leave me
> wondering if it is intended to imply cases or interpretations with which
> I disagree.
I am glad you think each point sounds reasonable. I am not trying to
slip anything by you. Please let me know how you might disagree with
possible interpretations of the various points.
> To use your original text as an example, "compatibility with all hosts"
> seems to imply that the solution can not start by modifying some of the
> hosts. I know that you have argued that a solution based on host
> modification is untenable, and this is a topic on which we have disagreed.
The new text is not so absolute. All 10 points are "Broadly speaking
. . ." which I intend to meaning something like "These are good
general principles - and that any deviation from them would require a
convincing argument".
Please give an example of how a scalable routing solution could be
widely adopted (or adopted at all by end-user networks in general, in
the early stages) if it required some form of host changes in order
for it to deliver compelling benefits for the adopting networks. For
instance:
1 - Changes to host stacks or applications in other networks.
(A non-starter, I think we all agree.)
2 - Changes to all applications in the adopting network.
(Likewise, a non-starter, I am sure.)
3 - Changes to the some or all applications in the adopting network.
4 - Changes to stacks in some or all hosts in the adopting network.
Please give examples of why such changes might be an essential
element of any scalable routing solution which would be generally
superior to alternative solutions which require no such changes.
Please also give some examples of how particular types of end-user
network might be motivated to make such changes.
I am not opposed to host changes on an optional basis. For instance,
Ivip has optional ITR functions in sending hosts - not behind NAT,
but on ordinary ("RLOC") or Ivip-mapped micronet ("EID") addresses.
My concern is about a scalable routing solution requiring host
changes in some or all hosts in order for it to deliver the
compelling benefits needed for widespread voluntary adoption.
> I absolutely agree that deployment has to have value for the deployer,
> in a reasonable and practical deployment scenario. And the deployer
> must not lose the ability to talk to the rest of the world in exchagne
> for that value.
I think we all agree on this.
> Most of the implications I see do not quite match up with the way
> you chose to phrase things below.
> An example in the first paragraph below is that the question of what the
> deployment path is, and when the bulk of users see value, and what value
> they see, varies depending upon the solution. Nothing will be
> "voluntarily adopted by the great majority of ..." early in its
> introduction. The path to widespread adoption is tricky for any
> technology.
OK - here is a version which hopefully overcomes this problem - the
addition of "over a period of years".
A successful solution to the routing and addressing
scaling problem is tightly constrained by the need
for it to be voluntarily adopted, over a period of
years, by the great majority of end-user networks of
all sizes who want or need multihoming, inbound
traffic engineering and/or portability of their
address space between ISPs.
Please point out any other problems with implications you foresee and
suggest any other things which could be improved.
BTW, I used an invalid address Brian Dickson. I think it should be:
Brian Dickson <[email protected]>
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
