Subject: Re: [rrg] Constraints due to the need for widespread voluntary adoption

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 20:42:20 -0500 (EST)

> From: Dae Young KIM <[email-masked]>

    > No, my 'ID' means a name which is location 'independent'.

OK, so apparently you have two kinds of names: "IDs", which are location
independent; and "locators", which are location dependent, but have local
scope only. In other words, you have no names which are i) location
dependent, and ii) have global scope.

So here is the problem: how do you compute paths across the entire
internetwork when you do not have any location-dependent names with global
scope for places in the network? The path-selection algorithm _has_ to have
such names to be able to compute paths across the internetwork.

    >> I am "J. Noel Chiappa" no matter where I am, and you can identify me
    >> without knowing either i) where I am, or ii) how to get there.

    > OK, you're talking about DNS name(or URI?).

No, you need to think separately about i) the characteristics of the name,
and ii) what it being named. "J. Noel Chiappa" is the name of a person, me. I
do not have a permanent location, and my name has no location information in
it. 

"[email-masked]" is a name - but the _kind of thing_ it is the name of, is
an email-box. "123 Main Street" is the name of a place - and maybe sometimes
the person named "J. Noel Chiappa" is at the place named "123 Main Street".
But that does not make the name of that person "123 Main Street".

    > Then, we said DNS name should be mapped to ID. (Noel to 234 Madison
    > Ave.)

?? You just said (above) that the "ID ... is location 'independent'".

    > There's no routing (or better said locating?) without identifying your
    > house.

My current house does not have a location-independent name. The only name it
has it a name that is location dependent (i.e. something like "123 Main
Street").

    > There's no identifying your house without successfully locating it.

I am from Bermuda. When I was young, houses in Bermuda had names - but the
names were not location dependent. Our house was named "Parquito". Even
though the house had a name which uniquely identified it (it was the only
house in Bermuda with that name), I guarantee you that that name would not
really help you locate it.

    > Put it in another way using the terms in this community:
    > - Do routing with ID.

We call that 'flat' routing (i.e. the names used for path selection are not
aggregatable, since they contain no location information - like Ethernet MACs
in a large, bridged Ethernet network).

That does not scale to very large (Internet-sized) networks.

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 6 Dec 2009 00:05:27 +0900

Hi, Noel,

I had a look the two renowned papers you recommended, which happened to be
know also to me (by author name, not by doc #), and my conclusion is,
they're almost there, but the model is wrong (more humbly, different) to me.
Even with Saltzer, it's still confusing enough as he already suggests at the
latter part of document.

So, rather than responding to your comments piece by piece, let me try to
phrase my model, hopefully, briefly.

1. Pre-positioned fundamentals: (, rationales for which being provided at
the end)

    1.1  Name, id, address are one and the same thing
    1.2  There's no such thing as hierarchical. Every thing(name, id, addr)
is, in fact, flat in its ultimate nature. 'Hierarchical' is just temporary
illusion.
    1.3  Distinction between location-independence and location-dependence
is not really there, meaningless. Only (network) graphical significance is
there.
    1.4  Nothing needs to be global. being unambiguous within a domain of
interest is enough; usually called 'local'. Cascaded horizontal mappings
ensures global uniqueness/unambiguity.

So, before taking off, clean your brain, please. Clean slate. :-)

2. Fundamentals of networking

    2.1. In networking, there's only one atomic function, which is BINDING.
    2.2. If the binding is between two entities in adjacent layers, it is
called MAPPING.
    2.3. If the binding is between two entities in the same layer, it is
called ROUTING.

3. Corollaries

    3.1. Picturing there are only three things to identify, i.e., Name, ID,
PoA, is an illusion. Depending on how deep you dig into the internal
structure of any specific layer, there can be much more things to identify.
Think of overlays, and think of, for example, the internal structure of
network layers, data-link layers, ATM layers, etc.
    3.2. There is, in the interest of networking, only incremental
bi-lateral relationship between two immediate neighboring entities; either
two being in the same layer or each being in adjacent layers.
    3.3. Entity, name, ID, address all be used interchangeably.
    3.4. Relaying (between two adjacent-hop nodes) can be considered as a
degenerate case of routing.
    3.5. Relations among entities in the same layer are represented by a
(network) graph. Routing is executed through a cascade of binding between
adjacent nodes.

4. Re-describing the usual ID/Loc Separation model:

    4.1. Application layer mapping (possibly with the help of DNS) binds an
application name to a node ID. Data is down-streamed through this binding.
    4.2a. A node acquires knowledge of the network graph consisting of nodes
in the same layer in the same domain, by use of a given routing algorithm,
e.g., link-state.
    4.2b. The source node selects the next-hop node from the graph in an
attempt to reach its destination node, and so binds, in the routing table,
its own ID with that of the next-hop node. (The destination node ID in the
packet header remains intact all through the routing, in this example
scenario.)
    4.2c. All referencing to nodes are done by node IDs. Therefore, it can
be said that routing is done by use of IDs. (In this context, you might
prefer to use the synonymous term 'address'.)
    4.2d. Nodes acquire, through a separate protocol like ARP, mapping
information between node ID to sub-network address (e.g., MAC address) of
all nodes attached to the same sub-network.
    4.2e. The source node consults this mapper constructed like above to
bind the next-hop node ID with the MAC address at which the next-hop node is
attached to. (In this picture, PoA is, in fact, about the binding of these
two.)
    4.2f. The source node passed the packet down to the MAC layer with the
information, (my MAC addr, next-hop MAC addr)-imbedding-(my node ID,
destination node ID).  [*Note: The destination node ID doesn't change.]
    4.2g. The next-hop node receives whatever frames pointing to its
associated MAC address. Upon opening the frame, if the destination ID
matches its own, it absorbs the packet. Otherwise, it does it turn of
routing-binding, and repeats the same procedure as the previous-hop node.
    4.2h. A node can have multiple PoAs, or put in my terminology, multiple
mappings of node-ID-to-MAC-address. Selection of a specific mapping out of
these multiples have already effectively be done in selecting the next hop
in 4.2b above.
    4.3. The sub-network layer (or MAC layer) repeats the same or equivalent
processes described in 4.2.

5. Consequences

    5.1. The procedures of 4.1, 4.2, 4.3 are all, in fact, equivalent. That
is, the same procedure can, if necessary, repeats over and over. So,
overlaying is inherent.
    5.2. Multi-homing and mobility are all done by the mapping procedure.
The ID may not change, but the sub-network address can change by ISP
switching and/or node moving. Engineering challenge is how to make this
mapping fast enough for given purposes.
    5.3. There is no need to have ID and Locator separately. Just node ID is
enough. There's no need for locator, i.e., identifier for PoA. Location (so
called) information comes from the underlying layer. Locating my next-hop
node is the job of the underlying layer.
    5.4. You may say node ID is static or global. But if your application
should be ported onto another device/node/handset, the node ID might have
too change, too. Then, you can say ID is local. That is to say, everything
is relative.
    5.5. You may say sub-network address (or locator in your term) is
location-dependent, bears location information. But your network also can
move; NEMO. Are you going to renumber your moving network every time you
move to different part of the global network so that your network address
bear location context? Trying to distinguish whether a address (locator, ID,
name) is location-dependent or location-independent is meaningless. Only
contextual significance of entities in the graph of peers in the same layer
and under same administrative authority (domain...?) is what counts.
    5.6. It may now seem obvious also to you that hierarchical
naming/addressing bears only partial significance. Even if you have your
locators (PoAs) hierarchical, it loses its location imbedded location
context if your network also moves around like in NEMO. Hierarchy though is
useful in table look-up in your mapping data base. However, memory can also
be virtual. So, after all, everything ultimately is 'flat'; at least in the
sense of 'location'. Again, where you are in the network graph is important;
you who may be moving. After all, the term 'location' is only causing
unnecessary confusion. We don't need locators.

6. Conclusion.

Now I did my exercise. Please tell me where I did my homework wrong.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 6 Dec 2009 01:12:49 +0900

One supplementary not before you attack me. In 4.2a, link-state is just an
example. Also, domain means here any administrative authority in one layer.
You can call it enterprise if you will.

You'll ask 'what about Interdomain-routing'?, which is the real issue here.

To me, it's all the same. Binding/mapping/routing among gateways works the
same way. And whenever you have to cross the admin/authority boundary where
name/address lose their context, you do horizontal binding.

In fact, I'm not a native English speaker and by now am not sure whether I
chose right terms; binding, mapping, routing. Or should they be 'mapping,
binding, routing'?

At least what I'm saying is

       There's only one thing A.
       If A is done vertically, we call it B.
       If A is done horizontally, we call it C(=routing).

If my model is of any value, please help me choose right terms.

On Sun, Dec 6, 2009 at 12:05 AM, Dae Young KIM <[email-masked]> wrote:

>     4.2a. A node acquires knowledge of the network graph consisting of
> nodes in the same layer in the same domain, by use of a given routing
> algorithm, e.g., link-state.
>     4.3. The sub-network layer (or MAC layer) repeats the same or
> equivalent processes described in 4.2.
>
> 5. Consequences
>
>     5.3. There is no need to have ID and Locator separately. Just node ID
> is enough. There's no need for locator, i.e., identifier for PoA. Location
> (so called) information comes from the underlying layer. Locating my
> next-hop node is the job of the underlying layer.
> http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>
>

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Robin Whittle <[email-masked]>
Date: Sun, 06 Dec 2009 14:03:10 +1100

Hi DY,

There's a long history of theoretical discussion about routing in the
RRG.  Your last two messages were highly theoretical.

Do you have a proposal for solving the routing scalability problem?

If so, does it involve changes to host operating systems and/or
applications?  Would your proposal be at odds with any other of these
constraints which arise from the need for voluntary adoption?

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

If you have a proposal, please describe it in more concrete terms,
with examples etc.

There are many ways of designing a global network which has no
routing scalability problems.  Our task is to provide a fix for
today's Internet - the IPv4 Internet, and for the IPv6 Internet so
that the same scaling problems won't occur if and when it is widely
used.  We can't force people to adopt anything, though there is some
scope for altering IPv6 before anyone starts using it on a
large-scale for general public use.

This task has been likened to converting a propeller-driven passenger
aircraft into a modern passenger jet - while it is flying.

However this analogy does not depict the constraints imposed by the
need for widespread voluntary adoption - adoption which will
typically be motivated by immediate benefits and not by concern about
scalability.

As with the aircraft analogy, the process of change needs to occur
with the network fully operating - so existing addressing and
protocols to hosts, and many other things, need to function normally
during and after the changes.

Some people seem to think it is good enough to solve IPv6's scaling
problems and then wait for the billion-plus users to migrate from
IPv4.  I don't accept this because no-one has been able to convince
me that this mass adoption and therefore non-reliance on IPv4 will
happen any time in the foreseeable future.

If your proposal doesn't alter host requirements at the operating
system or application level - for all IPv4 hosts operating today -
and if it has a chance of meeting the other constraints due to the
need for voluntary adoption, I will attempt to understand and discuss it.

If you don't have a proposal, perhaps you could critique the most
prominent proposals:

   LISP   http://www.lisp4.net
   APT    http://www.cs.ucla.edu/~meisel/apt-rrg.pdf
   Ivip   http://www.cs.ucla.edu/~meisel/apt-rrg.pdf
   TRRP   http://bill.herrin.us/network/trrp-rrg.pdf

all of which I think could meet the 7 absolute constraints imposed by
voluntary adoption, and would work with both IPv4 and IPv6.

  - Robin

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 6 Dec 2009 13:10:21 +0900

Hi, Robin,

So, you still don't catch the implication of my model. OK, I'll draft a
description of the routing scenario that this name/address scheme would
generate in a few days, to meet to the constraints you raised.

A question before that.

Is the list of constraints already a general consensus of this RRG? Does
silence mean acceptance? You say like this is a firm consensus whatsoever,
but I don't think I remember there's been any explicit statement like that.
If you will, would you ask the RRG chairs put your constraint at the
beginning of the proposal lists so that it be taken as an absolute basis? Or
have I missed something already done in that manner?

For example, your 3rd constraint says:

  3 - Therefore, the solution must be compatible with
      all hosts (stacks and applications) and routers
      in non-upgraded networks.

So, you're asking compatibility with all non-upgraded hosts and routers,
don't you? It looks to me as if you're going to fix the real problem inside.
Just patching on it. You're going to inject more drug into the body or an
extra artificial organ beside the real problem area.

Or your wording comes to me as if you were asking to cut flesh without
spilling a drop of blood. I'm already chocking.

On Sun, Dec 6, 2009 at 12:03 PM, Robin Whittle <[email-masked]> wrote:

>   APT    http://www.cs.ucla.edu/~meisel/apt-rrg.pdf<http://www.cs.ucla.edu/%7Emeisel/apt-rrg.pdf>
>   Ivip   http://www.cs.ucla.edu/~meisel/apt-rrg.pdf<http://www.cs.ucla.edu/%7Emeisel/apt-rrg.pdf>

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 6 Dec 2009 13:12:15 +0900

I mean you're not:

   '... as if you're going to fix the real problem inside...'

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Robin Whittle <[email-masked]>
Date: Sun, 06 Dec 2009 19:38:34 +1100

Short version:    Some folks can see a way of solving the routing
                  scaling problem via changes which would be widely
                  voluntarily accepted - which in part means
                  that the new system does not require any changes
                  to host stacks or applications.

                  Of these, some would be happy with the outcome in
                  the long-term (except no-one is happy about IPv4's
                  limited address range) and others would see these
                  changes as a half-way house to something better -
                  involving new software for hosts, at least new
                  stack software and probably new stack-app

                  interfaces - so new application code too.

                  Other folks can only see a solution by changing
                  protocols to something more elegant and correct -
                  which means changes for host stack and app code and
                  changes to most or all routers.

Hi DY,

You wrote:

> So, you still don't catch the implication of my model. 

No - I have no clear understanding of what you were writing about.  I
could have written a page or two about why I disagree with my
understanding of your first two points.  I didn't because of my
impression that any proposal might emerge from your framework would
not be suitable for voluntary adoption.

> OK, I'll draft a

OK - if it looks like it might be suitable for voluntary adoption, I
will read it and post my comments to the list.  If not, I think other
people would be interested in discussing it.

> A question before that.
> 
> Is the list of constraints already a general consensus of this RRG? 

Only the co-chairs Lixia and Tony can determine consensus.  I think
this list of constraints has fared pretty well so far, because a
number of people have been commented on it and because those people
have supported it, without major criticisms.  Also, the comments have
led to fruitful discussions.

> Does silence mean acceptance? 

Silence on a mailing list could mean either it is boring and not
worth honouring with a comment, or that it is OK.  Generally, unless
something is completely ridiculous, if someone puts up a document
which anyone strongly disagrees with, at least one person will point
out what is wrong with the document.  No-one has written that this
list contains things which are not real constraints - although the
last 3 are more "sliding scale" constraints compared to the absolute
nature of the first 7.

> You say like this is a firm consensus
> whatsoever, but I don't think I remember there's been any explicit
> statement like that. 

I have never said there is consensus on this.  Only Lixia and Tony
can determine that.  I have asked if there is consensus on it, hoping
to prompt people into agreeing or disagreeing and to prompt Lixia and
Tony into leading a discussion on it.

I think that that it would be good to include a list of constraints
in the RRG recommendation.  There are constraints due to other things
we can't change, but I think the list of constraints due to the need
for voluntary adoption is very important and should be given prominence.

> If you will, would you ask the RRG chairs put your
> constraint at the beginning of the proposal lists so that it be taken as
> an absolute basis? Or have I missed something already done in that manner?

Yes, as I just mentioned.

I think this question illuminates a distinction in viewpoints among
RRG members.   I think there's a group of people I will call "A" who
believe something like this:

  1 - The routing scaling problem is urgent enough that we should
      fix it in the foreseeable future - which means in the IPv4
      Internet first, and with less urgency, and ideally in a similar
      manner, in the IPv6 Internet.

  2 - There is a way which we can do this within the constraints of
      voluntary adoption.

Within this group, I think opinions vary as to:

  3 - Whether or not we can or should attempt to ensure the scalable
      routing solution also achieves other goals, such as making
      mobility more practical (including perhaps for IPv4) or
      some other goals, such as multicast on a global basis, easier
      transition to some other network such as IPv6 or something
      else.

  4 - How elegant and long-term desirable the upgraded IPv4 or
      IPv6 network would be - and therefore whether the upgrade
      should be a stepping stone to something different in the
      not-too-distant future.

On the other side are the "B" people who think something like:

  5 - We can't fix the routing scaling problem (and achieve any other
      goals which should be achieved at the same time, such as making
      the Internet protocols sufficiently elegant, secure, efficient
      etc.) with anything which could be introduced smoothly on a
      voluntary basis.

  6 - This means we shouldn't bother trying to fix the IPv4 routing
      scaling problem.  We should focus on an enhanced IPv6 or some
      other system.  Adoption will come when IPv4 becomes unworkable,
      due to address shortage and/or the routing scaling problem
      (which I think are somewhat interdependent).

I entirely disagree with these people, so its best if I don't try to
represent what their views might be.

Some folks see sufficient benefit in a scalable routing solution to
make it worthwhile - and can see how this could be introduced
voluntarily.  However, they do not regard that result as an
acceptable long-term outcome, so they envisage a transition beyond
that to something quite different - something involving new
approaches to naming, identification and addressing - something
involving major changes to host stack and application software.  So
those are the "A->B" team!

I am on the A team.  If I can think of a way of making the scalable
routing solution for IPv4 also ease transition to some new network
which is scalable and has a big addressing range, then I will make
this a separate proposal and so join the A->B team.

> don't you? 

I am not asking for it.  I would prefer it if we could redesign the
Internet without these constraints.  I am saying that as far as I
know, we need widespread voluntary adoption and that one of the
conditions of this is that the new scheme must work well (with little
or no degradation in performance, security, robustness etc.) with
existing hosts, routers and networks.

> It looks to me as if you're not [word added according to DY's next message] 
> going to fix the real problem inside. Just patching on it. 

Sure - the core-edge separation schemes (LISP, APT, Ivip and TRRP)
are a patch.

>From the point of view or architectural purity and excellence, that
is a problem - because to achieve these goals you need to redesign
everything.

>From the point of view of people actually achieving a better
Internet, it is a feature that the core-edge separation schemes are a
patch - because redesign is not an option.

> You're going to inject more drug into the
> body or an extra artificial organ beside the real problem area.

As I wrote in a recent message, maybe it would be kinder and better
for us all in the long term if someone killed IPv4 right now and
everyone was forced to adopt IPv6, which at least has enough address
space - and then we could develop a scalable routing solution for
IPv6 which would enable widespread adoption of a new Internet without
the 3.7B address limit of IPv4.  Or maybe it would be kinder to kill
IPv6 too and force us all to move to another Internet which was even
better.

These are hypotheticals.  There are immense forces at work to keep
IPv4 working as well as possible, whatever its limitations.  Look how
hooked most of us are on Windows and QWERTY keyboards.

The IPv4 Internet is far and way the world's biggest and most
entrenched IT system.  It has absolutely no backwards compatible
upgrade path to any other addressing system or set of protocols.  Its
utility is primarily dependent on the fact that it currently connects
every single host which anyone wants to be globally accessible.  The
IPv6 Internet or any other attempt at creating a global Internet
can't interoperate with the IPv4 network and its existing hosts, so
there is no seamless upgrade path.

The core-edge separation schemes are intended to largely eliminate or
reduce the IPv4 scaling problem - or at least to stop it getting much
worse, while enabling tens of millions to perhaps billions of
networks to have their own address space, which is portable between
ISPs, and can be used for multihoming and inbound traffic engineering.

With the exception of the IPv4 address range limitation, I envisage
an outcome which I think will be pretty elegant.  With Ivip, I have
plans for avoiding encapsulation overhead between ITR and ETR and so
for for avoiding PMTUD problems caused by that.  I have a mobility
scheme which would work well for both IPv4 and IPv6 with full
connectivity to existing mobile hosts, and generally optimal paths.

I think it is the correct approach to put a lot of workload for
routing and addressing in edge and near-edge devices such as ITRs and
ETRs (though the ITR function can often be done well in the sending
host).  I am opposed to the idea of putting more workload on the
hosts, which AFAIK is a characteristic of all the "let's really fix
the Internet" proposals.

Some people, perhaps including yourself, want to see a very simple
"network" with the hosts doing more work than they do now, to
maintain a logical address for communications to work from, which is
separate from their physical address.

I am opposed to this and will write about this in a separate thread.

Yes - I am modifying the patient's perhaps imperfect body, but I
think the result will be pretty good (except for the IPv4 address
range limitations) and I argue it would be better than burdening all
hosts any responsibilities regarding routing and addressing beyond
what they have now.

> spilling a drop of blood. I'm already chocking.

I am saying that we can't forcibly do anything to the way the great
majority of people use the Net - and we need to change this in order
to solve the routing scaling problem.  No-one has yet disagreed with
this - AFAIK, everyone agrees we are bound by the need for voluntary
adoption.

As far as I know the only way we can solve the scalable routing
problem or make any other changes to how most people use the Net is
to devise things people which people will happily adopt for their own
immediate reasons, which will also (if used very widely) achieve our
goals of solving the scalable routing problem.

 - Robin

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 6 Dec 2009 19:41:10 +0900

Hi, Robin,

I've got your point, and yes, very persuasive indeed.

Well, I must be totally wrong, but I thought, in the RRG meeting discussions
a while ago in Hiroshima, there were some comments that we might reconsider
and look for a long-term fundamental approach. So, I thought there could be
another camp of B or at least A/B. I must have been seriously mistaken.

If what you describe in length was really the fundamental baseline of this
group, then I shouldn't waste your time anymore, for already quite a number
of smart patch solutions aimed to solve the urgent and immediate dilemmas
have been developed for the last some two years. Watching which solution
will be picked, however, won't be boring, so I'll be around in the back for
the time being.

Thank you.

-- 
Regards,

DY
http://cnu.kr/~dykim