Fred, Thank you for your comments, but the last call for the document closed on Nov. 12.
Tony On Nov 23, 2010, at 7:09 AM, Templin, Fred L wrote: > See below for my comments on sections 3.4 and 3.5: > > Fred > fred.l.temp...@boeing.com > > 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 > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
