Subject: Re: Order in the working-group!

From: Lars-Johan Liman <[email-masked]>
Date: Mon, 05 Jul 1999 18:46:57 +0200

Since Friday som more facts have been revealed in this I-D issue.

It seems my archiver software hasn't kept up during May, which led to
me using incorrect information in the debate.

I feel I owe an apology to Masataka Ohta for jumping to conclusions,
and I still hope that we can find a working solution to this in Oslo.

I have also recieved comment that I have managed to stop technical
discussion on the shared root server issues. That was not my
meening. My meening was to make sure that you take all aspects into
account, and comment on both documents.

				Cheers,
				  /Liman

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 6 Jul 99 21:50:39 JST

Liman;

> I feel I owe an apology to Masataka Ohta for jumping to conclusions,

Thank you.

> account, and comment on both documents.

I'm afraid a way of thiking to consider order more important
than chaos of discussion is the way to stop the discussion. :-)

You could just have said "Fight!".

As for Hardie's draft, I can not understand why unique IP address
of root servers must be confined AS local.

As was discussed in MInneapolis, the source of possible problem is
advertisement of shared addreses, not unique ones.

							Masataka Ohta

---

From: Andras Salamon <[email-masked]>
Date: Tue, 6 Jul 1999 18:49:44 +0200

> advertisement of shared addreses, not unique ones.

On a somewhat related note, has anyone looked at
draft-catalone-rockell-hadns-00.txt?  (Implementation of a High
Availability DNS System, by G. Catalone and R. Rockell, from Sprint.)

Seems to me to share some ideas with
draft-ietf-dnsop-shared-root-server-01.txt except it considers caching
servers meeting local demand from within the AS, instead of root servers.

Perhaps the general principle of local address announcements for DNS
servers is useful enough that both aspects can be considered at once?

-- Andras Salamon                   [email-masked]

---

From: [email-masked]
Date: Tue, 6 Jul 1999 11:23:49 -0700 (PDT)

> advertisement of shared addreses, not unique ones.

I'm not sure what you mean by "confined AS local".  If your question
is "Why should the shared-unicast addresses have a single origin AS?",
then the answer is rfc 1930, section 7.  If the question is why should
they have a single administrative point of contact, then the answer is
that it is considerably easier for those using the servers, as they
don't have to figure out which box is misbehaving before reporting a
problem.  This was a point Randy Bush made very strongly in
Minneapolis.  

If you mean something else by "confinded AS local", please explain
further.  Citing the text in the draft you would like to discuss would
be particularly helpful.

				Ted Hardie

---

From: [email-masked]
Date: Tue, 6 Jul 1999 11:37:54 -0700 (PDT)

I hadn't seen the draft; thanks for pointing it out.  It doesn't go
into a great of detail about their deployment experience, but it does
indicate that they have deployed a system using of the same basic
ideas.  Their aim not to leak the shared unicast address is a bit
different, though, and some of the implied methods might have a a
significant performance hit.
			regards,
				Ted Hardie

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Jul 99 12:34:58 JST

Hardie;

> I'm not sure what you mean by "confined AS local".

You wrote:

  unicast address associated with the root name server.  The other
  interface, referred to as the AS-internal interface below, should
  use a distinct address specific to that host.  The host should

There is no reason to make host specific, globally unique,
address AS local.

It actually is harmful only to disable inter-AS zone transfer.

> If your question

Wrong question.

> problem.  This was a point Randy Bush made very strongly in

I'm afraid you are not familiar with internet routing with BGP
and ASes nor its associated problems.

With your proposal, there are multiple ASes sharing the same
IP address ranges.

Your proposal does not make the shared address have a single origin.

That a host can reach only a single host among many sharing the
same address is of course regardless of whatever proposal you
make (unless you say multicast), which does not mean there is
only a single AS using the IP address.

To your surprise, it is OK to have multiple ASes sharing the same
IP address ranges.

As I don't think it worth to repeat the past discussion, see the
mailing list archive after it is restored.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Jul 99 12:49:45 JST

Andras;

> servers meeting local demand from within the AS, instead of root servers.

Interesting.

They might have applied my idea draft of which was available in May.

Or, they reached the same solution independently.

Anyway, routing tricks does not solve a failure of DNS server
on a host with perfectly working routing system.

Thus, we need multiple IP addresses of DNS servers to try.

Their proposal still increase the chance of survivability if
DNS server is unreachable becasue of routing problems,though.

> servers is useful enough that both aspects can be considered at once?

As a demonstration to BGP-related WG on a possiblity to how to use
BGP wisely, maybe.

But, it is a bad idea to put everything into a single draft.

I even avoided to put things on gTLD servers.

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Tue, 6 Jul 1999 18:15:57 -0700 (PDT)

> draft-catalone-rockell-hadns-00.txt?

this but one example of how many large isps do this.  kind of them to write
it up.  these experiences are why we are suggesting looking at doing it with
roots.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 6 Jul 1999 18:13:43 -0700 (PDT)

> then the answer is rfc 1930, section 7.

i think he was pretty explicit about it being the unique address, not the
shared one he was discussing.  as ohta-san is usually pretty specific, i
am still trying to sort out what exactly he is suggesting.

randy

---

From: [email-masked]
Date: Wed, 7 Jul 1999 09:04:09 -0700 (PDT)

Masataka,

> There is no reason to make host specific, globally unique,

Based on this passage in your draft:

   A possible problem of such addresses is that the shared addresses can
   not be used for global communication. So, it is suggested that the
   root name servers with the administratively scoped shared unicast
   addresses have additional globally unique unicast addresses, which
   may be used for global communication such as zone transfer.

We seem to agree that there should be two addresses, one shared and
one unique.  If you check section 1.2 of my draft, you'll see that I
proposed using the unique address for delivery of zones and
administrative tasks.  If the term "AS-internal" gave you the
impression I meant that address was not globally unique and routable,
the term should certainly be changed.  How does "Shared unicast" and
"Administrative" interfaces strike you as a set of terms to use for
further discussion?

> > is "Why should the shared-unicast addresses have a single origin AS?",

Thanks for clearing that up.

> and ASes nor its associated problems.

Assuage your fears, Masataka, and be at peace.

> Your proposal does not make the shared address have a single origin.

Not true.  See section 1.5:

  The organization administering the mesh of servers sharing a unicast
  address must have an autonomous system number and speak BGP to its
  peers.  To those peers, the organization announces a route to the
  network containing the shared-unicast address of the root name
  server. 

> mailing list archive after it is restored.

I believe I have a complete local archive, if you would like to point
me to previous message-ids.

				Ted Hardie

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 8 Jul 99 7:34:18 JST

Hardie;

>   network containing the shared-unicast address of the root name

I'm now having an impression that you are talking about a set
of default resolvers sharing a single unicast address locally
in a single organization, which is already covered by:

	draft-catalone-rockell-hadns-00.txt

Do you understand the difference between the root servers and
local resolvers?

Anyway, your proposal does not make the shared address have a single
origin, which is an Internet-wide issue.

						Masataka Ohta

---

From: [email-masked]
Date: Wed, 7 Jul 1999 16:36:22 -0700 (PDT)

Masataka,

> Do you understand the difference between the root servers and

Yes.  Thank you again for your continuing concern.  

> origin, which is an Internet-wide issue.

Yes, it does.  That's the point of section 1.5.  Is it possible that
this passage has confused you?

  The organization's border routers must then deliver the
  traffic destined for the root name server to the nearest
  instantiation.  To avoid internal routing difficulties, a static
  route to that network is recommended.

Reading it, I can see that the mention of a static route might cause
someone to believe that a static route from external peers to the root
server is required or recommended.  One of the reviewers of a
pre-release version of the draft indicated that it might be easier for
the organization to manage their internal routing if a static route
from the border router to the nearest instance of the root server
network were used.  That's certainly not the only way to do it,
though, and if it is confusing the larger issue, it should be cut from
the draft.

For those who did not pick up a copy of draft
draft-ietf-dnsop-shared-root-servers-00.txt before it was replaced,
the text is at draft-hardie-dnsop-shared-root-servers-00.txt .

				Ted Hardie

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 8 Jul 99 11:21:27 JST

Hardie;

> Yes.  Thank you again for your continuing concern.  

Then, I can't understand how your proposal makes sense.

You wrote:

  To those peers, the organization announces a route to the
  network containing the shared-unicast address of the root name
  server.

which means multiple organizations, each of which having its own
AS numbers, are the multiple origins of the shared address.

That there is consistent routing in an organization does not
mean a single address have a single origin.

							Masataka Ohta

---

From: [email-masked]
Date: Thu, 8 Jul 1999 09:00:47 -0700 (PDT)

Masataka,

> AS numbers, are the multiple origins of the shared address.

I believe I begin to see the source of your confusion.  Look
back in the abstract:

  These practices presume that a single entity remains 
  administratively and operationally responsible for each 
  of the distributed servers.

This should probably be updated to say something like "distributed
server groups", because I mean that the whole paper presumes a single
organization handles all of the servers associated with a single
shared unicast address.  So ISP FOO might handle z.root-servers.net,
with distributed copies at various places in its network topologies.
I initially used the language "each of the distributed servers",
because I presumed that the practice might be common for operators
of root servers.  

				Ted Hardie

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 9 Jul 99 12:48:05 JST

Hardie;

> shared unicast address.

Thank you for the clarification. I think I can understand why some
people show so negative attitude for the shared addresses.

							Masataka Ohta