In einer eMail vom 23.11.2010 16:10:30 Westeuropäische Normalzeit schreibt [email protected]:
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. 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 protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
