Subject: [rrg] RRG Mobility Architecture

From: [email-masked]
Date: Wed, 29 Jul 2009 12:05:09 EDT

In einer eMail vom 26.07.2009 23:05:18 Westeuropäische Normalzeit schreibt  
[email-masked]:

I like  the idea of viewing broadband subscribers whose addresses  
change  frequently as a subset of mobile nodes.  This is a particularly   
interesting case, because when they "roam" there is no "home  network"  
that can be reached using their former address, so some  existing  
mobility mechanisms wouldn't work in this  case. 
Margaret

Suggestion: The RRG group may also discuss the importance and impact  of IP 
Mobility for a scalable routing architecture on this Friday. Wrt above:  
Eventually by also envisioning roaming users who are ALWAYS roaming, i.e.  
without any home (agent).
 
Heiner

---

From: [email-masked]
Date: Wed, 29 Jul 2009 17:44:59 EDT

In einer eMail vom 29.07.2009 22:24:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

It's a  worthy endeavor to understand how two hosts that both always move
and have  no home rendezvous.

Eliot

:-) I had only in mind a scenario where just one (source) party is homeless 
 i.e. all the time on the go.
May be that the associated service which I remember is not perfectly  
adequate (sorry for that): I remember a telephone feature where  a service man 
had no home station but just a chip card with special  service authorization 
bits on it which he could plug into other phone sets  while visiting other 
people's places .
 
After all I only suggested to also discuss IP Mobility and would be  
interested in the outcome.
As to avoid any misunderstanding: my favorite solution for the scalability  
problem is based on associating the geographical coordinates of the  
closest DFZ-routers with the individual users' IP addresses (RFC1712).  Hereby no 
IP Mobility is involved at all.  
 
But my speculation is this: Maybe further aspects show up in the mobility  
discussion for which from geo-coordinates derived identifiers might be  
beneficial too.
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 30 Jul 2009 09:31:58 -0400 (EDT)

> From: RJ Atkinson <[email-masked]>

    > Eliot sought an example, so I provided *an example*.
    > 
    > Now you and Eliot have both gotten bogged down in the example, and
    > discussion of architecture seems gone from the thread.

I propose we call this behavioural pattern "IETF disorder", since it's so
common in the IETF! (Ducks! :-)

	Noel

---

From: [email-masked]
Date: Thu, 30 Jul 2009 14:13:53 EDT

In einer eMail vom 30.07.2009 16:35:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

On   30 Jul 2009, at 09:54, Eliot Lear wrote:
> On 7/30/09 3:24 PM, RJ  Atkinson wrote:
>>
>> On  30 Jul 2009, at 02:40, Scott  Brim wrote:
>>> I just wonder if they all should be solved with  the same mechanism.
>>
>> I suggested that we needed an  architecture that supports the
>> broad range of issues before the  RG.  Eliot sought an example,
>> so I provided *an  example*.
>>
>> Now you and Eliot have both gotten bogged  down in the example,
>> and discussion of architecture seems gone  from the thread.
>
> I raised engineering constraints that we need  to consider when  
> designing
> a system, and by no means  all of them.  Determining the point at which
> that crosses to  architecture should occur directly after we've counted
> the number of  angels on a pin.

No.  You saw it yourself.  As soon as the  phrase "engineering
constraints" appears, one has left architecture behind  and crossed over
into engineering.

Mind, it is very important to get  the engineering right.  The Internet
community keeps learning the hard  way that it is also very important
to sort out the architecture BEFORE  crossing over into engineering.

This is the kind of thing that jnc and  some others of us have been
saying for a few years now on this list, so it  is neither a new thought
nor uniquely  mine.

Yours,

Ran

IMHO, the problem with the RRG is that it is completely backward  oriented. 
Today each handphone is able to take advantage of the geographical  
coordinates/GPS. But routers of even a future routing architecture still must  not.
 
Ran pointed out that scaling is not all. Indeed, I have also stressed many  
times the many advantages by viewing the internet topology. 1-2 years ago I 
 asked the rtgwg-folks whether their first accomplishment was the end or 
the  beginning. The answer I got: the beginning. But since then nothing 
occurred.  Multipath forwarding can be substantially extended, not just ECMP and 
not just  what the rtgwg did, but as well detours  which even start out with  
crankback, entirely connection-less,  - yes, intra-domain  wise  But in 
inter-domain routing there is not even a rear mirror.  Hence neither a COMPLETE 
Multipath forwarding nor adequate TE (as to deal with  traffic congestion) 
can be done. Will say: intra-domain routing could be  improved 
substantially, but in the same sense inter-domain routing, too. I could  repeat the 
entire list again and again what is prevented so far....
 
Since quite a while I realized that it  will take some years till  the LISP 
worship is over. So I keep being patient but allow me to speak up  whenever 
this group gets stuck again with the same old problems.
I remember the July meeting 2000 in London. It was said: well we have this  
problem, but no rush, we have a ten years time frame. Now we have July  
2009.
 
A second reply wrt to the "users without home agent" point. At first, it is 
 only relevant that just one, i.e. the destination is without home agent. 
And  yes, a reasonable service could be to search for this user, in the case 
where  the source has only an idea inside which geo-patch the destination 
might  currently be located.
 
Heiner

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2009 20:55:31 +0200

[resending, with two edits]

I'm sorry, Ran.  I shouldn't have been quite so flippant.  BUT.

The architecture v. engineering debate is a red herring that gets thrown
around too easily.  Every PhD student has to do a literature survey to
understand what has been done, in order to demonstrate that there is at
least something new to do that will improve society.  That is what is
needed here.  Nothing more, and certainly nothing less, and it has been
woefully lacking in the past.  N.B., I am not asking that we get stuck
in history– that is a favorite pastime of this organization, but there
is a balance between the two extremes.

If we are going to create a new mobility architecture we should
understand how the existing ones work and don't work, and recognize what
is worthy of our time and what is not.  We've all done the numbers. 
What I stated were common pitfalls the conversation usually follows like:

    * trying to solve the problem exclusively at L3, a favorite within
      the IETF.  You and I know that not considering these problems from
      the transceiver to the application means poor deployment (more on
      this later).
    * not using the right tool for the right purpose.  I'll spare the
      guilty parties, but you know who you are.
    * simply not understanding what problem they are solving, and what
      problems to leave for others.  How many efforts (and perhaps
      entire companies) have failed because of scope?  The IETF perhaps
      goes to the other extreme now, but we'll leave that alone.
    * attempting to shoehorn every last problem into a solution.  I
      believe in the need for locator/id separation, but it is *not* a
      panacea.  For instance, use of different *locators* may have
      involve different costs, that may need to be exposed all the way
      to the application layer.  The iPhone demonstrates this best of
      all with some of its apps.  And so the app can't simply cope with
      an identifier, as many would like.  It has to have additional
      information (although it may not need the locators themselves).

But back to that literature survey thing.  People are often quite hard
on MIPv6, and often for the wrong reasons.  While MIPv6 bind times have
often been viewed as atrocious, often ranging from 20-60 seconds, in
many instances that has been due to poor signaling in the layers below. 
The real problems with MIPv6 (putting aside triangular routing in MIP)
is the need for v6, firewall impedance mismatch, and poor interaction of
the layers above and below L3.  There are assuredly other problems I'm
not mentioning, like the complexity of dealing with private address
spaces.  HIP implementations have some of these problems.  But that is
often times it- we may in fact have the right *Internet* *standards* but
need work elsewhere.  And some of this, such as FW traversal may be just
poor incentive alignment, or scope creep, depending on how you view the
problem.  How do you view the problem?

To restate my main point: if we're going to design a new system, we had
darn well better understand the old systems, and what their limits are.

Eliot