Subject: [rrg] Clarification

From: Toni Stoev <[email-masked]>
Date: Sun, 25 Jul 2010 18:02:30 +0300

Researchers,

I think we must not attack each other personally. Nor even each other's views.
We need to find the best solution each of the design goals.

Here we talk about identity/location split. Robin is against. Most but seem to be for.
So with the identity/location split we encounter identifier uniqueness. Whether it has to be global/universal or just local. Some hesitate about this; others, like me, take universal uniqueness for natural.
Next question: Uniqueness system is to be hierarchical or flat? Any arguments on flatness side? But there is a ready-made solution. Is it reliable?
Are we going any further with this ambiguity?

I propose this approach: Let's answer the questions the reverse way.

1. Hierarchical or flat uniqueness system?
2. Global/universal or just local uniqueness?
3. Shall we make identity/location split?

Good will
Toni

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jul 2010 07:02:23 +0200

I think that before we decide whether we are for or against a locator/identifier split, we need to pick a single definition for what the locator is and a single definition for what the identifier is. LISP refers to the IP address of a certain router as a "locator" and the IP address of an end system as the "identifier", and splits them by making them different layers in a tunnel-like (map/encapsulation using an ip/ip tunnel header) overlay network. ILNP and other GSE-derivitives make the IP prefix the "locator" and the IP End Point Identifier the "identifier", and split them in the sense that the identifier is consistent end to end but locator is fungible at stated points in the network according to a set of rules and therefore has different degrees of locality.

I personally am in favor of the latter (ILNP ideally, http://tools.ietf.org/id/draft-mrw-behave-nat66 as a fall-back position which I suspect will be easier to deploy as it does not require host changes), and not in favor of the former. 

My reasoning is that the ILNP model is a win-win between edge and transit networks, giving them both a direct solution to a problem that they have said publicly and loudly that they would like to see fixed, while LISP is (in my opinion) not.

The problem we set out to solve recognized a fundamental difference of opinion being battled out in the RIR communities. Edge networks, as a class, want to be independent of their upstream networks. They want to be able to change upstreams without a significant level of effort in renumbering or changing their routing. They generally don't want a large route table, and generally solve this using default routes to their upstreams, potentially tuned with a few more-specifics for key business partners. Their solution in IPv4 is either IPv4/IPv4 NAT, which has operational problems for several classes of applications, or PI addressing, which explodes the route table by enumerating the edges. Transit networks, as a class, prefer or don't object to having their customers captive to them, and want a route table of a manageable size. For them, a PA allocation - allocation that enumerates only the points where the edge attaches to the transit core - achieves that goal.

I prefer the GSE model, instantiated in ILNP, because it gives the edge networks the relative simplicity of management and independence they seek - their network appears to them as if it were PI - while giving the transit networks the relative simplicity of management and route table effects of a totally or mostly PA network. Both sides win. The route table in the backbone enumerates the folks in the world that have AS numbers, whether they are truly ISPs or whether they are simple complex edge networks. The edge networks are independent of their upstreams with the added benefit of being able to address systems in their own and other edge networks statelessly, uniquely, and exactly, just as if addressing were truly end to end, and allows for predictable load sharing across DMZs in parallel, which IPv4/IPv4 stateful NAT does not. 

I don't believe that LISP does that. It does simplify the transit domain - addressing in that domain is PA. Outside the transit domain, addressing remains PI, and the complexities implied by that are moved from the transit domain (which has expertise in handling that) to the edge (which does not). I think it makes the network harder for the edge to attach itself to without expert help.

BTW, I have a similar opinion of shim6, although the wording of the argument is different. shim6 makes the entire network PA, which is good for the transit networks, and makes multihomed edge networks bear the complexity burden of maintaining routing for each prefix they use throughout their networks. The edge, I fear, lacks either motivation or expertise to offload the complexity from the transit core.

As to your proposed questions, I think they make a false assumption - that we have four options on the table:
 - one with a hierarchical system and Global/universal characteristics, 
 - one with a hierarchical system and local characteristics,
 - one with a flat system and Global/universal characteristics, and
 - one with a flat system and local characteristics.

I'm not sure the proposals are malleable in that way.

On Jul 25, 2010, at 5:02 PM, Toni Stoev wrote:

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

http://www.ipinc.net/IPv4.GIF

---

From: William Herrin <[email-masked]>
Date: Mon, 26 Jul 2010 08:39:38 -1000

> 1. Hierarchical or flat uniqueness system?

If you pick global for #2 then the raging success of the DNS at
extraordinarily large scales makes the answer obvious.

If you pick local then the extra management overhead of a hierarchical
system makes the answer equally obvious. There's a -reason- enterprise
users often work with bare IP addresses instead of DNS names inside
their local systems and it's not because they're dumb or lazy.

> 2. Global/universal or just local uniqueness?

For which component of the system? Either answer is obviously correct
depending on which component you're talking about.

For the communication's initiator finding the acceptor? How would we
structure a non-global uniqueness system?

For associating packets with ongoing traffic between a particular pair
of hosts where one of them is an anonymous client? Most global systems
you could construct suffer byte overhead, management overhead, a loss
of desirable anonymity for the initiator, or all three.

> 3. Shall we make identity/location split?

Do you accept that overloading network topology, packet association
and finding the remote service all onto the same data element in the
packet is the root cause of our routing problem? If so then "don't do
that" would seem to be an obvious part of the solution.

Then again, that's also the punchline to, "Doctor, my arm hurts when I
move it this way." We should understand and perhaps even enumerate
what value lies in overloading before deciding to do away with it.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jul 2010 10:42:40 +1200

Fred,

On 2010-07-26 17:02, Fred Baker wrote:
...

> BTW, I have a similar opinion of shim6, although the wording of the argument is different. shim6 makes the entire network PA, which is good for the transit networks, and makes multihomed edge netwo…

To be precise, I believe that it's the basic IPv6 addressing model, in which
a site or a host may simultaneously use as many different prefixes as it
cares to, that creates the routing and administrative burden on sites.
SHIM6 simply makes use of that model, and inherits the burden.

There's a fair amount of evidence from the real world that site IT managers
don't like that burden, being accustomed to the IPv4 world where you're
lucky if you even get one prefix of your own.

Also see draft-troan-multihoming-without-nat66, which very directly
addresses this question.

    Brian