[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] What does "architectural" mean?
In "Re: [RRG] Moving forward..." you wrote:
> You are not in the non-consensus camp :-)
Yes, but that consensus may be too rough and too restrictive for the
RRG to continue with. I understand from the recent discussion
between Tony, Bill and perhaps others that the question of whether
we need to pursue an IPv4 solution or not:
Our recommendation should be applicable to IPv6. It may or may
not also apply to IPv4, but at the very least must provide a path
forward for IPv6.
is up for discussion or at least a more formal vote.
> I had some private exchange with Tony on this issue, but let me put it
> in public to help the consensus gathering: I agree that the solution
> must work for IPv6, but at the same time,
> - IPv4/v6 share the same architecture; the only major fundamental
> difference is their address space size.
I think this is far too broad-brush. As Bill Herrin and I have
argued, IPv6's address space, low installed base and lack of urgency
about routing scaling make for a much wider set of possible
solutions, developed over a longer time frame, than would be
possible with for IPv4.
> - my notion of the RRG task is to develop an architectural
> solution to routing scalability.
How do you define "architectural"?
Do you mean changing the very nature of the thing to be something
which has no scaling problems? I think of map-encap as an
architectural addition, but other people may regard it as a kludge:
a bolt-on thing which is inelegant and poorly integrated with the
current architecture. So to them, map-encap is not an architectural
> - We should step up a level from looking specific versions of
> IP at this stage of solution development. Our solution has to be
> an architectural change, and should work for either version.
As just noted, I think this is too abstract and would lead to a
discussion which ignores important distinctions between IPv4 and
IPv6. My previous message suggests we pursue three avenues of
research at once, since I think we can't reliably rule out any of
them at present.
to unsubscribe send a message to firstname.lastname@example.org 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