Hi, Robin,
So, you still don't catch the implication of my model. OK, I'll draft a
description of the routing scenario that this name/address scheme would
generate in a few days, to meet to the constraints you raised.
A question before that.
Is the list of constraints already a general consensus of this RRG? Does
silence mean acceptance? You say like this is a firm consensus whatsoever,
but I don't think I remember there's been any explicit statement like that.
If you will, would you ask the RRG chairs put your constraint at the
beginning of the proposal lists so that it be taken as an absolute basis? Or
have I missed something already done in that manner?
For example, your 3rd constraint says:
3 - Therefore, the solution must be compatible with
all hosts (stacks and applications) and routers
in non-upgraded networks.
So, you're asking compatibility with all non-upgraded hosts and routers,
don't you? It looks to me as if you're going to fix the real problem inside.
Just patching on it. You're going to inject more drug into the body or an
extra artificial organ beside the real problem area.
Or your wording comes to me as if you were asking to cut flesh without
spilling a drop of blood. I'm already chocking.
On Sun, Dec 6, 2009 at 12:03 PM, Robin Whittle <[email protected]> wrote:
> Hi DY,
>
> There's a long history of theoretical discussion about routing in the
> RRG. Your last two messages were highly theoretical.
>
> Do you have a proposal for solving the routing scalability problem?
>
> If so, does it involve changes to host operating systems and/or
> applications? Would your proposal be at odds with any other of these
> constraints which arise from the need for voluntary adoption?
>
> http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
>
> If you have a proposal, please describe it in more concrete terms,
> with examples etc.
>
> There are many ways of designing a global network which has no
> routing scalability problems. Our task is to provide a fix for
> today's Internet - the IPv4 Internet, and for the IPv6 Internet so
> that the same scaling problems won't occur if and when it is widely
> used. We can't force people to adopt anything, though there is some
> scope for altering IPv6 before anyone starts using it on a
> large-scale for general public use.
>
> This task has been likened to converting a propeller-driven passenger
> aircraft into a modern passenger jet - while it is flying.
>
> However this analogy does not depict the constraints imposed by the
> need for widespread voluntary adoption - adoption which will
> typically be motivated by immediate benefits and not by concern about
> scalability.
>
> As with the aircraft analogy, the process of change needs to occur
> with the network fully operating - so existing addressing and
> protocols to hosts, and many other things, need to function normally
> during and after the changes.
>
> Some people seem to think it is good enough to solve IPv6's scaling
> problems and then wait for the billion-plus users to migrate from
> IPv4. I don't accept this because no-one has been able to convince
> me that this mass adoption and therefore non-reliance on IPv4 will
> happen any time in the foreseeable future.
>
> If your proposal doesn't alter host requirements at the operating
> system or application level - for all IPv4 hosts operating today -
> and if it has a chance of meeting the other constraints due to the
> need for voluntary adoption, I will attempt to understand and discuss it.
>
> If you don't have a proposal, perhaps you could critique the most
> prominent proposals:
>
> LISP http://www.lisp4.net
> APT
> http://www.cs.ucla.edu/~meisel/apt-rrg.pdf<http://www.cs.ucla.edu/%7Emeisel/apt-rrg.pdf>
> Ivip
> http://www.cs.ucla.edu/~meisel/apt-rrg.pdf<http://www.cs.ucla.edu/%7Emeisel/apt-rrg.pdf>
> TRRP http://bill.herrin.us/network/trrp-rrg.pdf
>
> all of which I think could meet the 7 absolute constraints imposed by
> voluntary adoption, and would work with both IPv4 and IPv6.
>
> - Robin
>
>
>
--
Regards,
DY
http://cnu.kr/~dykim
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
