On Wed, 17 Sep 2003 15:34:25 -0700
Dave Crocker <[EMAIL PROTECTED]> wrote:
> Keith,
>
> KM> DNS names are not sufficient for rendezvous or referral.
>
> Here are the arguments about the names, themselves, that you put forward:
>
> KM> * Incompatible with existing transport protocols.
>
>
Keith,
KM> DNS names are not sufficient for rendezvous or referral.
Here are the arguments about the names, themselves, that you put forward:
KM> * Incompatible with existing transport protocols.
If you mean that they are too long to be carried in IP packet headers, you are
of course corre
On woensdag, sep 17, 2003, at 22:59 Europe/Amsterdam, Keith Moore wrote:
a protocol that depends on the random kindness of remote routers
won't fly.
I have no problem with trying to choose a signaling protocol that won't
look like an attractive target to ignorant sysadmins, or with trying
to pic
Erik,
EN> I don't think an identifier is necessary in every packet.
EN> But I do think it makes sense to have a shim layer above IP which
EN> uses locators in the packets below (for IP's routing) and presents
EN> fixed length identifiers in the pseudo-headers passed to/from the upper layer
EN> pro
> > we can design protocols to tolerate transient failures; but we
> > cannot design protocols that work no matter what arbitrary
> > filtering the network imposes.
>
> I agree in principle but in practice a protocol that depends on the
> random kindness of remote routers won't fly.
Obviously I
On woensdag, sep 17, 2003, at 22:40 Europe/Amsterdam, Keith Moore wrote:
You're making a host of assumptions here. One of them is that even
though the info is requested per-host, it exists as per-site.
no, I'm not making that assumption. the only assumption I'm making
is that the mappings from i
> > Having the routers cache id-to-loc mappings is one thing; having
> > them perform id-to-loc mappings is something else entirely. Yes,
> > the hosts will still generate such requests, but those requests
> > don't have to traverse the entire network if the local router knows
> > what to do with
On woensdag, sep 17, 2003, at 14:58 Europe/Amsterdam, Keith Moore wrote:
Having the routers cache id-to-loc mappings is one thing; having them
perform id-to-loc mappings is something else entirely. Yes, the hosts
will still generate such requests, but those requests don't have to
traverse the
On woensdag, sep 17, 2003, at 14:22 Europe/Amsterdam, Pekka Nikander
wrote:
What exactly do you want to change about the APIs and transport
protocols?
Well, I do not exactly /want/ to change the APIs or tranport protocols.
I only *anticipate* that due to mobility, multi-address multi-homing,
and
Hi Pekka,
> Well, I do not exactly /want/ to change the APIs or tranport
> protocols. I only *anticipate* that due to mobility,
> multi-address multi-homing, and intermittend connectivity, we
> end up making changes to the transport protocols, anyway. I
> also anticipate that if we take the i
> first try to overcome the handicap that id/loc
> mapping at the host level will generate hundreds or thousands more
> _times_ requests than on a router-based basis, two or three orders
> magnitude more.
Having the routers cache id-to-loc mappings is one thing; having them perform
id-to-loc mapp
Iljitsch,
I was not really discussing backwards API issues either. If we go
for a real separation of locators and identifiers, we will also
have to define new APIs in the longer run. And slightly revised
transport protocols, too.
>
>
What exactly do you want to change about the APIs and transpor
Hi,
A couple of comments on deprecate-site-local draft. In general, I think
the doc is very good, but could use a bit boosting in a couple of areas
(which -00 draft wouldn't.. :-)
substantial
---
Although the consensus was far
from unanimous, the working group decided in its meeti
13 matches
Mail list logo
