See below for my comments on sections 3.4 and 3.5:
Fred
[email protected]
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.
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 protected]
http://www.irtf.org/mailman/listinfo/rrg
