Re: My ID on addressing
Paul Tsuchiya <tsuchiya@thumper.bellcore.com> Tue, 12 January 1993 04:06 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24669;
11 Jan 93 23:06 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24665;
11 Jan 93 23:06 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27141;
11 Jan 93 23:07 EST
Received: by thumper.bellcore.com (4.1/4.7)
id <AA16021> for ietf-archive@nri.reston.va.us; Mon, 11 Jan 93 23:05:29 EST
Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7)
id <AA16017> for /usr/lib/sendmail -oi -fowner-pip X-pip;
Mon, 11 Jan 93 23:05:27 EST
Received: by chiya.bellcore.com (4.1/4.7)
id <AA02979> for pip@thumper.bellcore.com; Mon, 11 Jan 93 23:05:26 EST
Date: Mon, 11 Jan 93 23:05:26 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Tsuchiya <tsuchiya@thumper.bellcore.com>
Message-Id: <9301120405.AA02979@chiya.bellcore.com>
To: Garrett.Wollman@uvm.edu, pip@thumper.bellcore.com
Subject: Re: My ID on addressing
>
> PIP folks:
>
> Before my holiday vacation, I put out an ID on what I have called
> "NAP-based addressing." Unfortunately, I was not explicit enough in
> my request message, so it got filed under the DNS WG (I had expected
> it to be draft-wollman-...). Oh, dear, another mailing-list I have to
> join and see what they're saying about me.
I suggest that you try to pry it loose from the DNS WG. I can't
imagine that they'd know what to do with it.......
>
> In any event, I'd like to encourage everybody to take a look at
> draft-ietf-dns-nap-00.{txt,ps}, and let me know what you think. The
> ideas set out there are basically my idea of how to solve the
> Addressing Problem and the Mobile Host Problem (which I guess we could
> call "ROAD-complete", by analogy with "AI-complete") in the context of
> PIP, in a way which doesn't completely break the architecture of the
> existing DNS.
>
Many of the ideas in this draft we are incorporating into
our implementation of DNS for Pip, including the mobile
host stuff, and using DNS to help provide transition info.
We are providing other stuff as well, such as the PDN
address the endpoint can be reached through.
I'd say that we are generally in the spirit of
what you are proposing (that is, levereging DNS to get more
useful routing/policy info without really changing the dynamics,
such as they are, of dns).
We'll have a rough rough outline of our spec out in a few
days........
The one thing I either didn't understand or didn't agree
with in your spec is the NAP identifiers. I couldn't figure
out if the NAP identifiers are used just to talk to NAPS,
or if they actually become part of the address as it is
encoded in the packet.
Probably you could clear it up for me by giving an example
of the process you describe in paragraph 4 of section 2.4.
There you talk about querying local and foreign NAPs, and
getting fragments in return. I don't really understand
this part.
The architecture that I am thinking of (that hasn't really
been published yet.....sorry) has "Pip Header Servers" that
exist between the host and DNS. That is, the DNS requrest
goes to a Pip Header Server, which forwards the DNS request,
gets various information, possibly including routing info,
and decides what the FTIF chain should look like. If
routing info is not included, however, border routers can
give the appropriate redirects.
I'd guess that I am trying to do with the pip header server
that you are doing with the NAPs, so I'd like to see how
we differ in approach......
Thanks,
PX
- My ID on addressing Garrett.Wollman
- Re: My ID on addressing Paul Tsuchiya
- Re: My ID on addressing Garrett.Wollman