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

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Andrew Partan <asp@partan.com>

    > 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