Subject: Re: [rrg] Comments on rrg-design-goals-04

From: [email-masked]
Date: Tue, 23 Nov 2010 13:06:21 EST

In einer eMail vom 23.11.2010 16:10:30 Westeuropäische Normalzeit schreibt  
[email-masked]:

See  below for my comments on sections 3.4 and  3.5:

Fred
[email-masked]

3.4.  Decoupling  location and identification

Numerous sources have noted  that an IPv4 address embodies both host
attachment point  information and identification information.  [IEN1]
This  overloading has caused numerous semantic collisions that have
limited the flexibility of the Internet architecture.

FLT >>  OK.

Therefore, it
is desired that a  solution separate the host location information
namespace from  the identification namespace.

FLT >> Not OK. Change to:  "Therefore, it is desired that a solution
FLT >> provide the host  with an identification and/or endpoint address
FLT >> that remains  stable even if the location change. 

Also not ok. In the current internet (I am not talking about  LISP) there 
is no location
information as opposed to identification information, hence you cannot  
separate
related namespaces. The sentence is logically not correct.
 
Fred is right (hereby I assume that he uses  "identification" and  
"endpoint address"  as two synonyms.  
 
Heiner

Caution must be taken here to clearly distinguish  the decoupling of
host location and identification  information, and the decoupling of
end-site addresses from  globally routable prefixes; the latter has
been proposed as  one of the approaches to a scalable routing
architecture.  Solutions to both problems, i.e. (1) the decoupling  of
host location and identification information and (2) a  scalable
global routing system (whose solution may, or may  not, depend on the
second decoupling)

FLT >>  OK.

are required and it is required that  their
solutions are compatible with each other.

FLT  >> Not OK. I think Robin is right that we will not see a
FLT >>  combination of disparate solutions such as ILNP+IRON both
FLT >>  being deployed in conjunction. What is quite possible, however,
FLT  >> is a combination of IRON+HIP since HIP is only instrumenting
FLT  >> the hosts and can be used perfectly well over an IRON network.
FLT  >> Still, why would such a combination be *required* when it may
FLT  >> not actually even be desireable in all cases? Suggested change
FLT  >> is to replace the above phrase with the phrase: "are possible."   

3.5.  Scalable support for mobility

Mobility  is the capability of a host, network, or organization to
change its topological connectivity with respect to the remainder  of
the Internet, while continuing to receive packets from the  Internet.
Existing mechanisms to provide mobility support  include

1.  renumbering the mobile entity as it  changes its topological
attachment point(s) to  the Internet;

2.  renumbering and creating a tunnel  from the entity's new
topological location back  to its original location; and

FLT >> Strike the phrase  "renumbering and". Renumbering would
FLT >> imply that the end  system's endpoint address changes
FLT >> when in fact it is only the  end system's locator address
FLT >> that changes. This is true for  both MOBIKE and Mobile IP,
FLT >> and also applies to the kinds of  mobility solutions
FLT >> associated with the CES  architectures.

3.  letting the mobile entity announce  its prefixes from its new
attachment  point(s).

The first approach alone is considered  unsatisfactory as the change
of IP address may break existing  transport or higher level
connections for those protocols  using IP addresses as identifiers.
The second requires the  deployment of a 'home agent' to keep track of
the mobile  entity's current location and adds overhead to the routers
involved, as well as adding stretch to the path of inbound  packet.
Neither of the first two approaches impacts the  routing scalability.
The third approach, however, injects  dynamic updates into the global
routing system as the mobile  entity moves.  Mechanisms that help to
provide more  efficient and scalable mobility support are desired,
especially when they can be coupled with security, especially
privacy, and support topological changes at a high-rate.

FLT >>  OK.

Ideally,
such mechanisms should  completely decouple mobility from routing.

FLT >> Not OK. It  should be perfectly OK for mobility to interact
FLT >> with the  routing system as long as the routing churn is
FLT >> localized and  minimized. Strike this  sentence.
_______________________________________________
rrg mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg