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

Reply via email to