Subject: Is Scope working well?

From: Akira Kato <[email-masked]>
Date: Fri, 09 Jul 1999 01:47:04 +0900

Beside the discussion related to "politicalness", I have a question
on the idea of "scope" in Mohta san's darft.

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?

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?

Last point I don't agree with is:
	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.

-- Akira Kato

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 9 Jul 99 9:18:39 JST

Kato-san;

> 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.

> "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 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

---

From: Akira Kato <[email-masked]>
Date: Fri, 09 Jul 1999 09:55:12 +0900

> root based on the AS path and other information.

Oops, I apologize that I missed to read "other information". So one
of the implemetations in which the server selection is performed in
the regular BGP route selection may comply with the draft.

>administrating both domains by the same ISP with the same set of

What I mean is that the model of operation just above can be practical.
However, the draft "requires" it is. 

Assume a stuation where a server is attached to an exchange point in
which 60 ISPs are connected and where they peer with the
serverm. Mohta san's requirement can be understood that the operators
of *all* ISPs must have responsibility on the server. I don't think
this is practical and necessary.

-- Akira Kato

---

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

Kato san;

> the regular BGP route selection may comply with the draft.

primarily on the second hop AS.

The detail of the selection is, as usual with BGP, a local
policy issue.

> However, the draft "requires" it is. 

No, it does not.

and the requirement/recommendation is still satisfied.

> this is practical and necessary.

Suppose a root server domain advertises a wrong route, which is
found by an operator at a distance from the IX.

As the AS number of the domain is shared by other domains containg
root servers with the same IP address, there is no information on
the single administrative contact of the domain.

Thus, the administrator of the second hop AS is the proper point
of contact.

The point of contact should be able to fix the problem of the
wrong route advertised not only through his AS but also through
other 59 ISPs.

Note that the draft does not forbid 60 ISPs jointly hire a single
operator for the root server domain. But, it is required that
operators of all the 60 ISPs can tell the shared operator to
fix the route problem.

In practice, the set of advertised route is fixed to be a
route to a single network that it is unlikely that any
routing problem occur.

And, I have noticed that I should add a sentence that the ASes
for root servers should be non-transit leaf. Can you agree
with me?

							Masataka Ohta