[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: existing proposals
itojun;
> >> Here are documents currently alive (there can be others):
> >> draft-ietf-ipngwg-ipv6-2260-00.txt
> >> draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt
> >> draft-bragg-ipv6-multihoming-00.txt (not discussed in 1999 interim)
> >> draft-ietf-ipngwg-default-addr-select-02.txt
> >All of them violate the end to end principle and does not work.
> >It is wrong to add intelligence to already too intelligent
> >routing system.
>
> In what sense it violates "end to end principle"? what led you to the
> conclusion?
> None of them modify routing protocols. The first 3 items are just
> routing configuration/opertional hints.
Assuming a relaying/tunneling entities in ISPs is a violation.
And, as I wrote:
> >End to end principle means that decision should be made based
> >only on host's local, which does not mean local to peer of
> >the host, information.
Making a selection based on the knowledge available on at
the other end is a violation.
> >As for source address selection, as Internet routes are heavily
> >assymmetric, it is wrong to assume that an end system can make a
> >good guess on routing environment of its peer, which means a
> >source can not make proper selection of its source address to
> >be used at its peer.
> >End to end principle means that decision should be made based
> >only on host's local, which does not mean local to peer of
> >the host, information.
>
> so, i guess you are saying that
> - if we rely on source address selection rule on the sender side,
> we are violating end to end principle.
Yes, of course.
> The goal of source address selection draft is clearly stated in
> section 1. From multihoming perspective, the goal for the source
> address selection is to use *seemingly better* source address for the
> peer to reply.
What is required for scalable multihoming is to let the peer know
all the addresses.
If the peer knows all the addresses, there is no reason for the source
make selection.
> The only guy who can pick the correct source address to use is,
> a guy knows about every states in all intermediate routes, nobody else,
> so it is impossible.
A host can try all the destination addresses to find the correct one.
The problem is that it takes time.
Local routing table gives proper order of destination addresses to
try (with some tie) to minimize the delay.
That's what is written in my draft.
> I don't agree with your wording: "violates end to end principle".
> There's no NAT involved, there's no header-rewriting 8+8 router
> involved. Please use appropriate term like "uses source address
> selection".
You think only NAT and Mike's routing goof (don't mention 8+8,
because there are better proposals before Mike proposed his
version) can violate the principle.
The reality is that people are so creative to invent innovative
ways to violate the principle.
> I agree (i took a glance into your draft):
> - session layer/modified TCP, which lets us endpoint address (unlike
> TCP), will make some part of problems go away.
> - socket API changes may help, but you may not be able to convince
> vendors out there.
> - drastic changes like 8+8, may help.
> However, we already are deploying IPv6 nodes, there are IPv6-enabeld
> TCP applications. If we think about real deployment, things we can do
> is very limited. IT IS TOO LATE FOR MAJOR CHANGE!
That is a familiar discussion often heard since IPv6 went to PS.
So, in your theory, you should have already achieved the real
depolyment. Conguratulations.
However, we, living in the real world, think that, without multihoming
issues solved, IPv6 addresses to be used for the real deployment can
not be assigned.
> BTW, only the last one (among 4 drafts) talks heavily about source
> address selection. I wonder how you concluded like below.
>
> >All of them violate the end to end principle and does not work.
As shown above, any proposal to assume
IT IS TOO LATE FOR MAJOR CHANGE!
automatically violates the end to end principle.
I'd like to propose that the charter of multi6 WG tolerate changes
on API or protocol, even though some people think the changes major.
Masataka Ohta