In that case, please just close the discussion and freeze the document on your discretion.
On Wed, Nov 24, 2010 at 12:51 AM, Joel M. Halpern <j...@joelhalpern.com>wrote: > I appreciate your taking the time to read the document carefully. > However, I am confused by most of your requested changes. > The changes seem to reflect some (there is plenty of disagreement) > conclusions that folks have reached during the course of the IRTF RRG work. > But the document is not the goals for some new set of work. It is the > goals we roughly agreed on early on. The purpose of publication is for the > historical record, not to drive some new set of work. New work will have to > define its own goals. > > I am also confused by your comment on the description of the existing > mobility solutions. I am pretty sure that there exist solutions with the > properties enumerated in the document. Given that existing solutions, while > they may have implicit notions of identity, do not have a clear distinction, > I do not see the problem with describing the existence of solutions which > use renumbering and tunnelling. We could, perhaps, debate which solutions > have that property. > > Yours, > Joel > > > On 11/23/2010 10: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 > -- DY
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
