Short version: Some folks can see a way of solving the routing
scaling problem via changes which would be widely
voluntarily accepted - which in part means
that the new system does not require any changes
to host stacks or applications.
Of these, some would be happy with the outcome in
the long-term (except no-one is happy about IPv4's
limited address range) and others would see these
changes as a half-way house to something better -
involving new software for hosts, at least new
stack software and probably new stack-app
interfaces - so new application code too.
Other folks can only see a solution by changing
protocols to something more elegant and correct -
which means changes for host stack and app code and
changes to most or all routers.
Hi DY,
You wrote:
> So, you still don't catch the implication of my model.
No - I have no clear understanding of what you were writing about. I
could have written a page or two about why I disagree with my
understanding of your first two points. I didn't because of my
impression that any proposal might emerge from your framework would
not be suitable for voluntary adoption.
> 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.
OK - if it looks like it might be suitable for voluntary adoption, I
will read it and post my comments to the list. If not, I think other
people would be interested in discussing it.
> A question before that.
>
> Is the list of constraints already a general consensus of this RRG?
Only the co-chairs Lixia and Tony can determine consensus. I think
this list of constraints has fared pretty well so far, because a
number of people have been commented on it and because those people
have supported it, without major criticisms. Also, the comments have
led to fruitful discussions.
> Does silence mean acceptance?
Silence on a mailing list could mean either it is boring and not
worth honouring with a comment, or that it is OK. Generally, unless
something is completely ridiculous, if someone puts up a document
which anyone strongly disagrees with, at least one person will point
out what is wrong with the document. No-one has written that this
list contains things which are not real constraints - although the
last 3 are more "sliding scale" constraints compared to the absolute
nature of the first 7.
> You say like this is a firm consensus
> whatsoever, but I don't think I remember there's been any explicit
> statement like that.
I have never said there is consensus on this. Only Lixia and Tony
can determine that. I have asked if there is consensus on it, hoping
to prompt people into agreeing or disagreeing and to prompt Lixia and
Tony into leading a discussion on it.
I think that that it would be good to include a list of constraints
in the RRG recommendation. There are constraints due to other things
we can't change, but I think the list of constraints due to the need
for voluntary adoption is very important and should be given prominence.
> 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?
Yes, as I just mentioned.
I think this question illuminates a distinction in viewpoints among
RRG members. I think there's a group of people I will call "A" who
believe something like this:
1 - The routing scaling problem is urgent enough that we should
fix it in the foreseeable future - which means in the IPv4
Internet first, and with less urgency, and ideally in a similar
manner, in the IPv6 Internet.
2 - There is a way which we can do this within the constraints of
voluntary adoption.
Within this group, I think opinions vary as to:
3 - Whether or not we can or should attempt to ensure the scalable
routing solution also achieves other goals, such as making
mobility more practical (including perhaps for IPv4) or
some other goals, such as multicast on a global basis, easier
transition to some other network such as IPv6 or something
else.
4 - How elegant and long-term desirable the upgraded IPv4 or
IPv6 network would be - and therefore whether the upgrade
should be a stepping stone to something different in the
not-too-distant future.
On the other side are the "B" people who think something like:
5 - We can't fix the routing scaling problem (and achieve any other
goals which should be achieved at the same time, such as making
the Internet protocols sufficiently elegant, secure, efficient
etc.) with anything which could be introduced smoothly on a
voluntary basis.
6 - This means we shouldn't bother trying to fix the IPv4 routing
scaling problem. We should focus on an enhanced IPv6 or some
other system. Adoption will come when IPv4 becomes unworkable,
due to address shortage and/or the routing scaling problem
(which I think are somewhat interdependent).
I entirely disagree with these people, so its best if I don't try to
represent what their views might be.
Some folks see sufficient benefit in a scalable routing solution to
make it worthwhile - and can see how this could be introduced
voluntarily. However, they do not regard that result as an
acceptable long-term outcome, so they envisage a transition beyond
that to something quite different - something involving new
approaches to naming, identification and addressing - something
involving major changes to host stack and application software. So
those are the "A->B" team!
I am on the A team. If I can think of a way of making the scalable
routing solution for IPv4 also ease transition to some new network
which is scalable and has a big addressing range, then I will make
this a separate proposal and so join the A->B team.
> 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?
I am not asking for it. I would prefer it if we could redesign the
Internet without these constraints. I am saying that as far as I
know, we need widespread voluntary adoption and that one of the
conditions of this is that the new scheme must work well (with little
or no degradation in performance, security, robustness etc.) with
existing hosts, routers and networks.
> It looks to me as if you're not [word added according to DY's next message]
> going to fix the real problem inside. Just patching on it.
Sure - the core-edge separation schemes (LISP, APT, Ivip and TRRP)
are a patch.
>From the point of view or architectural purity and excellence, that
is a problem - because to achieve these goals you need to redesign
everything.
>From the point of view of people actually achieving a better
Internet, it is a feature that the core-edge separation schemes are a
patch - because redesign is not an option.
> You're going to inject more drug into the
> body or an extra artificial organ beside the real problem area.
As I wrote in a recent message, maybe it would be kinder and better
for us all in the long term if someone killed IPv4 right now and
everyone was forced to adopt IPv6, which at least has enough address
space - and then we could develop a scalable routing solution for
IPv6 which would enable widespread adoption of a new Internet without
the 3.7B address limit of IPv4. Or maybe it would be kinder to kill
IPv6 too and force us all to move to another Internet which was even
better.
These are hypotheticals. There are immense forces at work to keep
IPv4 working as well as possible, whatever its limitations. Look how
hooked most of us are on Windows and QWERTY keyboards.
The IPv4 Internet is far and way the world's biggest and most
entrenched IT system. It has absolutely no backwards compatible
upgrade path to any other addressing system or set of protocols. Its
utility is primarily dependent on the fact that it currently connects
every single host which anyone wants to be globally accessible. The
IPv6 Internet or any other attempt at creating a global Internet
can't interoperate with the IPv4 network and its existing hosts, so
there is no seamless upgrade path.
The core-edge separation schemes are intended to largely eliminate or
reduce the IPv4 scaling problem - or at least to stop it getting much
worse, while enabling tens of millions to perhaps billions of
networks to have their own address space, which is portable between
ISPs, and can be used for multihoming and inbound traffic engineering.
With the exception of the IPv4 address range limitation, I envisage
an outcome which I think will be pretty elegant. With Ivip, I have
plans for avoiding encapsulation overhead between ITR and ETR and so
for for avoiding PMTUD problems caused by that. I have a mobility
scheme which would work well for both IPv4 and IPv6 with full
connectivity to existing mobile hosts, and generally optimal paths.
I think it is the correct approach to put a lot of workload for
routing and addressing in edge and near-edge devices such as ITRs and
ETRs (though the ITR function can often be done well in the sending
host). I am opposed to the idea of putting more workload on the
hosts, which AFAIK is a characteristic of all the "let's really fix
the Internet" proposals.
Some people, perhaps including yourself, want to see a very simple
"network" with the hosts doing more work than they do now, to
maintain a logical address for communications to work from, which is
separate from their physical address.
I am opposed to this and will write about this in a separate thread.
Yes - I am modifying the patient's perhaps imperfect body, but I
think the result will be pretty good (except for the IPv4 address
range limitations) and I argue it would be better than burdening all
hosts any responsibilities regarding routing and addressing beyond
what they have now.
> Or your wording comes to me as if you were asking to cut flesh without
> spilling a drop of blood. I'm already chocking.
I am saying that we can't forcibly do anything to the way the great
majority of people use the Net - and we need to change this in order
to solve the routing scaling problem. No-one has yet disagreed with
this - AFAIK, everyone agrees we are bound by the need for voluntary
adoption.
As far as I know the only way we can solve the scalable routing
problem or make any other changes to how most people use the Net is
to devise things people which people will happily adopt for their own
immediate reasons, which will also (if used very widely) achieve our
goals of solving the scalable routing problem.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
