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

From: "Michel Py" <[email-masked]>
Date: Thu, 3 Jan 2002 08:58:44 -0800

Alex,

> Alex Zinin wrote:
> My bad. The term was induced by some next gen addr/rtg architecture
> ideas, much in line with Noel's where the addresses are derived
> from the routing structure. PA would then be connectivity-based,
> while PI would not.

Reading it again, I would say it applies to my draft as well, since
the PI addresses are designed to carry topology requests and the PA
addresses the end-to-end traffic. Connectivity-based more or less
equates to end-to-end traffic, I think.

> To ensure efficient abbreviation of reachability information as
> it is distributed through a routing system, it is important to
> minimize (ideally eliminate) non-connectivity based information.

Agreed.

> Splitting the routing name and EID notions (routing and transport
> names) allows the routing system to bother with connectivity-based
> addresses only. Requiring EIDs to be routable essentially defeats
> the purpose of split---the same old problem is applicable to
> EIDs now.
>> Michel Py wrote:
>> For my model, I think that it would be appropriate to say:
>> resolve(name) = EID = PI address
>> locations = PA addresses
> Alex Zinin wrote:
> Still, in your case PIs need to be routable and routable
> through multiple SPs...

Yes, but they will not carry heavy traffic so the problem is somehow
not as bad as it is today (latency would not really matter).

There are two types of PI addresses:
(1) Centrally assigned PI addresses, much like what we have today.
(2) Tony's geo PI.
Note that Tony's geo PI are not mentionned in the version of the
MHTP draft you currently have.

The reason I kept centrally assigned PI addresses (1) is market
reality. Whatever we do, there will always be some people that will
get their prefix advertised into the DFZ. Instead of putting our heads
in the sand and pretend it will never happen, let's state that it
should be reserved to large multinational corporations and put a
very high price and hassle to get one of these and let's not make it
part of the DFZ but rather keep it separate (in the MHTP routing table).

Concerning Tony's PI (2), it can fly only if it is strongly aggregated.
Given the scope of these, there is not even a possibility not to
aggregate them. In this situation, a few geo aggregates in the DMZ would
not bother anybody.

Michel

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jan 2002 12:48:13 -0500

>>>>> "Michel" == Michel Py <[email-masked]> writes:
    Michel> The reason I kept centrally assigned PI addresses (1) is market
    Michel> reality. Whatever we do, there will always be some people that will
    Michel> get their prefix advertised into the DFZ. Instead of putting our heads
    Michel> in the sand and pretend it will never happen, let's state that it
    Michel> should be reserved to large multinational corporations and put a
    Michel> very high price and hassle to get one of these and let's not make it
    Michel> part of the DFZ but rather keep it separate (in the MHTP routing table).

  Why "corporations" here?
  Why not "organizations"?

  Certainly the "Mars Colony" would have a very clear reason to have
something in the DFZ.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [