Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments]

From: "Michel Py" <[email-masked]>
Date: Fri, 21 Dec 2001 07:50:47 -0800

>> Brian Carpenter wrote:
>> I think we have a missing requirement:

++ The solutions must include an analysis of their effects, if any,
++ on DNS updates,including consideration of load for the global
++ updating of the DNS, and interactions with DNS TTL and caching.

Agree. The ++ text above could, IMHO, go directly into the
requirements draft.

Michel.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 21 Dec 2001 11:51:01 -0500

> From: Andrew Partan <[email-masked]>

    > Not if you seperate EIDs from the routing goop. [Which then leads to
    > the question of how you get from an EID to the routing goop.]

In engineering terms, I've always felt that a separate mapping mechanism was
not necessarily a good idea. While it might make sense architecturally to
have separate namespaces for "endpoint identity" and "location", to allow the
binding between the two to change, when it came to the actual engineering, in
most cases one might find both out in a single packet cycle. In other words,
a single DNS transaction might return both the "endpoint identity" and
current address.

I don't have my feet completely in concrete on this, since I don't think
preventing extra packet exchanges is something we have to do at absolutely any
cost. (The number of packets needed to load the average web-page laden with
zillions of tiny images is pretty amazing, but I don't hear agonized moaning
about it all over.) If there's a good reason to pay the cost of an extra
packet exchange on a normal connection setup, then OK - but let's do it after
careful analysis indicates it's worth it, not just off the top of our heads.

(This is all separate from the issue of *whether* one would even want to be
able to look in a directory, based on an endpoint name, and find the
location(s) of that endpoint. One might use such a capability for error
recovery, fault analysis, etc, etc. Most people, when asked this, say "Of
course we want to be able to do that", but I'm frankly of two minds about it.
The question is whether the expense of maintaining that directory - and it
will be considerable - is worth it.)

    > I could see something that has the EID/routing-goop split

By "routing-goop", do you mean exactly the concept in GSE, or are you
speaking of a more generic "routing-name"?

    > and a different (non-DNS) solution of how you get from EIDs to the
    > routing-goop. The DNS would only deal with EIDs.

Why? What's the benefit? Do you have some design in mind that would have
substantially lower deployment (i.e. amount of code) or operational (i.e.
amount of packets/data) costs, or something?

I understand that dynamic updating might be an issue, but that's going to be
a problem no matter what system you keep the mapping in. I also understand
that DNS has problems, and maybe we really want son-of-DNS. But still, why
keep the two mappings in separate databases? What's the benefit, when you
look at the entire system?

	Noel

---

From: "Michel Py" <[email-masked]>
Date: Fri, 21 Dec 2001 19:45:42 -0800

J. Noel,

> J. Noel Chiappa wrote:
> If there's a good reason to pay the cost of an extra
> packet exchange on a normal connection setup, then OK
> - but let's do it after careful analysis indicates it's
> worth it, not just off the top of our heads.

These days, one more packet is a drop is the sea. On a typical
web page, there are a zillion references to other FQDNs that
each require a DNS query and a gazillion 3-pixel wide jpegs
that the trained brain of the heavy surfer does not even see that
each require establishing and tearing down a TCP connection.

My take is: if it's ONE extra packet, no point even discussing it.
More than ten packets, let's talk about it.

> (This is all separate from the issue of *whether* one would even
> want to be able to look in a directory, based on an endpoint name,
> and find the location(s) of that endpoint. One might use such a
> capability for error recovery, fault analysis, etc, etc. Most
> people, when asked this, say "Of course we want to be able to do
> that", but I'm frankly of two minds about it. The question is
> whether the expense of maintaining that directory - and it

It does not need to be a centralized directory. If the endpoint "name"
is addressable (I do not like "name" in this context as it implies
DNS but I will keep it for consitency) the endpoint itself can answer
queries about its own locations <== (more than one).

In the concept I propose, what you call name is a PI address, and
its locations are several PA addresses. The key is to make the name
itself addressable.

Michel.

http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt