Yawn Sent from my iPhone
On Mar 26, 2010, at 11:10 AM, "Robin Whittle" <r...@firstpr.com.au> wrote: > Listening to the audio of the meeting, I understand Lixia and Tony > have decided that the RRG Recommendation is for the Core-Edge > Elimination (Locator / Identifier Separation) architecture ILNP to be > further developed. Perhaps I missed something about the > Recommendation also involving Aggregation with Increasing Scopes - > but several people mentioned this was either a stop-gap, or involved > such complexities as to give them a headache. > > ILNP can't work for IPv4 and can only deliver significant routing > scalability benefits once all hosts: > > 1 - Adopt IPv6. > 2 - Have their stacks upgraded to ILNP. > > There are various critiques of how well ILNP would work, but even if > it worked as planned, it cannot be a solution to the only routing > scaling problem currently in existence (IPv4 - see: msg05946). > > So I think this Recommendation is wildly unrealistic. > > There is nothing in the Charter to suggest that we don't need to > worry about the IPv4 routing scaling problem. > > http://www.irtf.org/charter?gtype=rg&group=rrg > > The Charter mentions Mobility as part of the problem - but this has > been sidelined for most of the RRG discussions. > > At the moment, the Internet routing and addressing > architecture is facing challenges in scalability, > mobility, multi-homing, and inter-domain traffic > engineering. Thus the RRG proposes to focus its > effort on designing an alternate architecture to > meet these challenges. > > It is not clear that ILNP can handle mobility - yet I think it was > Tony, earlier this morning, who stated that current IP Mobility > arrangements are far from adequate. (I don't recall his words.) > > This Recommendation comes purely from the co-chairs. There has been > no attempt to test or seek consensus on this. > > Nor has there been a serious attempt to develop a set of design > goals, as was required by the Charter. The existing Design Goals ID > was never developed any further after its current draft, very early > in this phase of the RRG's work. There was no attempt to test > consensus support for it. > > Discussion of "proposals" (AKA "candidate architectures") was banned > or discouraged for much of the last three years. We were told to > discuss "architectural" matters - but there was little or nothing > from the co-chairs by example or by instruction on what this would > involve. > > The co-chairs did not encourage serious work on a taxonomy or > classification system for the various proposals/architectures. (I > have no idea why, today, they classed GLI/Split - which is a CEE > architecture - with the CES "map-encap" architectures.) > > No-one has argued the case for why it is better to burden all hosts > with extra work (CEE = Locator / Identifier Separation) than to add > some things to the routing system (CES) and leave the hosts alone, > using the current, highly efficient, naming model in which the IP > address plays both the Identifier and Locator roles. See the thread > "Why won't supporters of Loc/ID Separation (CEE) argue their case?" - > the first message links to messages arguing against CEE. > > It seems this Recommendation is unconcerned with practical matters > such as efficiency, minimising delay in establishing communications, > concern about the IPv4 scaling problem - or about the barriers > imposed by the need for widespread voluntary adoption: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > CES architectures can meet these constraints. CEE architectures > can't. > > > For anyone who wants to read my idea of what the RRG should have > recommended: > > http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html > > No-one else wrote what they would like to see in the Recommendation. > > This includes a general critique of Core-Edge Elimination (Locator / > Identifier Separation) architectures, including ILNP. > > I think Lixia mentioned that ILNP requires hosts to do "heavy > lifting". Indeed it does - see msg06219 for why all CEE > architectures require all hosts to do more work, send and receive > more packets, and frequently suffer significant delays in > establishing initial communications. These problems are worse for > any host, such as a mobile host, which relies on slow, potentially > congested, potentially unreliable links such as 3G wireless. > > - Robin > > > > > _______________________________________________ > 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
