Subject: [rrg] PI and ISP migration

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 11:04:58 +0900

(I'm perfectly OK with ILNP. I was just not comfortable with
terminologies. So much for that.)

As I confessed, I'm not a routing expert. So, please, folks, have some
patience with my asking from A and B.

As to the problem of routing scalability.

My curiosities are:

   1. Why, in the first place, did people allow sites to inject PI
addresses in DFZ? Why not simply reject PI in DFZ, limiting their use
strictly inside a site?

   2. As to sites that migrated across ISPs, why not simply throw away
old PA addresses injected into a new ISP that is not responsible for
service to such foreign addresses?

If the two operational rules had been kept strictly, then there would
not have been the problem of DFZ routing table explosion.

There must be some other compelling reasons why this could not have
been done. What are they?

And additionally,

   3. Is there any slightest chance that the authority (ICANN? IETF?)
resume to mandate such strict rules as above to bring back the
situation where it ought to have been?

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Sat, 12 Jun 2010 00:55:14 -0700

Hi,

> addresses in DFZ? Why not simply reject PI in DFZ, limiting their use

Because that doesn't solve the multi-homed site problem.

> service to such foreign addresses?

This is what normally happens.

> situation where it ought to have been?

Not without a credible solution to the multi-homed site problem.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 13 Jun 2010 08:59:03 +0900

Hi, Joel,

My apology for posting this back to RRG. I don't think your comments
are of any bad taste. They are very instructive true to the fact, for
which I thank you a lot.

My next, out of continued shallow knowledge as a novice, would be:

  o What not have introduced some mechanism similar ones recently
proposed with virtual prefixes.

  o Let user sites use PI prefixes.

  o With multiple ISPs, PI would be converted and be advertised as PAa
into the upstream ISPa while as PAb into the upstream ISPb.

  o Now that both PI and PA are distributed by a single authority,
that authority would keep/manage a mapping server, {PI, multiple PA}.

  o (I'd assume that PI is unique in their own number space across all
user sites.)

  o DNS would return (only?) return PI addresses. So, corresponding
users know only my PI address.

  o-i When my corresponding user injects the packet with PI
destination into the upstream ISP, that ISP would change the
destination to a PA address of the target receiver.

  o-ii Or the conversion might be required of the user themselves, and
they would consult the mapping server to get the other party's PA
address before asking the upstream ISP for delivery.

I'd hope you get the picture what I'm trying to describe here.

Wouldn't this solve the problem and keep only aggregatable
addresses/prefixes be going around in the DFZ?

Or, in the beginning of all these, was there no such idea in vision?

On Sat, Jun 12, 2010 at 11:38 AM, Joel M. Halpern <[email-masked]> wrote:
> This gets into a history lesson.
> While there are answers relative to IPv4, it is actually more informative to
> look at the IPv6 situation.
>
> When we produced IPv6, we actually wrote down a rule that said "no PI."
> IANA started allocating blocks to the RIRs.  The RIRs worked with their
> members to work out the allocation policies from those blocks.
> The IETF can produce recommendations, but the reality is determined by what
> the operators accept and what the RIRs hand out.
>
> The operators, and their customers, pointed out to the RIRs (whcih they
> control) two specific problems
> 1) Customers needed to be able to multi-home without using multiple
> addresses.  Multiple-addressing simply did not work right, and did not solve
> many of the problems.
> 2) Customers need to be able to change service providers without needing to
> renumber every device.  At that time, and even now, renumbering just doesn't
> work.
>
> These problems are described in the RRG problem statement.
> Due to these issues, the RIRs decided to hand out PI addresses.  The
> operators decided that they would allow this.  (It would actually take
> significant work on the routers to keep it from working.)
>
> Unless we can solve these problems, or change the operation so that these
> problems do not cause core scaling problems, it is demonstrably inevitable
> that we will end up with serious problems in the core.  (One can debate what
> will break first, with one of the choices being the pocketbooks of the
> operators.)
>
> This is the operational reality we live with.
>
> Yours,
> Joel
>
> Dae Young KIM wrote:
>>

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 13 Jun 2010 09:11:31 +0900

> Because that doesn't solve the multi-homed site problem.

I'd believe/hope that there could have been solutions for multi-homing
even with keeping this scenario, if people would have enough research
before ever starting to distribute PI addresses.

> Not without a credible solution to the multi-homed site problem.

I'd get a (ungrounded?) feeling that people themselves generated
problems and try to sweep it up with second-hand measure.

There's a proverb in my country:

  "To remedy the barn after a cow is stolen"

  "Smashed to the cheek in downtown, and spit in the river in the outskirt."

Considering all the pains that the whole community/industry has to go
through this series of aftermath remedy, I wished a considerably
smaller effort right in the early beginning might have eliminated this
tiny hole in the bank.

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Sat, 12 Jun 2010 17:56:31 -0700

> smaller effort right in the early beginning might have eliminated this

Agreed, but part of research is deploying, finding problems, and then
learning from your mistakes and fixing them.  If the same people had set out
fix all problems before deploying, then we wouldn't have the Internet today.

Tony