[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: kato@wide.ad.jp (Akira Kato)
Cc: dnsop@cafax.se
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date: Fri, 9 Jul 99 9:18:39 JST
In-Reply-To: <19990709014704O.kato@nezu.wide.ad.jp>; from "Akira Kato" at Jul 9, 99 1:47 am
Sender: owner-dnsop@cafax.se
Subject: Re: Is Scope working well?

Kato-san;

> The practicalness of scoped addresses is shown only by the
> proliferation of private address. We sometimes see the prefixes for
> the provate address space in the global internet routing table. This
> indicate us that complete prevention of the "leak" is not so easy
> otherwise implemented as the default configurations of many router
> implementations. Is there any good tool to declare a scope?

The draft does not require to prevent the "leak".

The draft does not require all the ASes have their own root servers,
which means "leak" is often desired.

It, instead, says:

   network operators may choose their favorite root server based on the
   AS numbers of the next hop ASes with, for example, AS path and BGP
   policy.

The network operators decide whether to accept or reject advertised
root based on the AS path and other information.

> Second point is the dynamicness of the "scope". I feel the scope
> Mohta san proposing is relatively static from the word
> "administratvely". Is this interpretation correct?

I merely borrowed the word from the multicast terminology, because
"anycast" is the rat hole.

I'm not sure what you mean "static" and "dynamic", but, depending on
the policy, upon route failure or resumption, root servers'
identities change dynamically.

Here, you can't expect more dynamism than that of routing systems,
can you?

(FYI, adminisratively scoped multicast addresses are so dynamic
that I don't think it work.)

> Last point I don't agree with is:

What are the previous points you don't agree with?

> 	operators of an AS adjacent to the root servers' AS be fully
> 	responsible to the operation of the root servers,
> (at the end of section 2)
> 
> I understand the operators of adjacent ASes should have some degree of
> responsibility on the transit service to/from the root server AS.  The
> responsibility of the operation of a root server should be on the
> operators of the root server.

I fully agree with you that I can't even find the last point.

The recommendation in the draft can be satisfied, for example, by
administrating both domains by the same ISP with the same set of
operators.

Or, a root server and its domain attached to an IX may be operated
by some consortium of ISPs, in which case, some of operators of
all the ISPs should be the operators of the root server.

						Masataka Ohta

Home | Date list | Subject list