Re: [rrg] Proposal for recommendation language

[Robin Whittle <[e-mail]>]

Hi Tony,

Thanks for providing a draft of your proposed text.

You wrote:

> Most comments are welcome.  In particular comments of the form "I'm not
> convinced, try again" of "based on this rationale, you should have picked
> proposal XYZ" aren't particularly helpful.  

So you don't want to know about any serious disagreement - you only
want help wordsmithing and strengthening your arguments.  But
strengthening your argument involves anticipating disagreement and
providing suitable counter-arguments.


> Comments (and in particular text
> contributions) that a) add points or clarify the message, b) improve the
> text either editorially or via wordsmithing, or c) otherwise improve the
> tone, strengthen the argument, or clarify the intent are very much welcome.

In that case, I suggest you remove the 17.2 text:

  On behalf of the routing research group,



> 17.  Recommendation
> 
>    As can be seen from the extensive list of proposals above, the group
>    explored a number of possible solutions.  Unfortunately, the group
>    did not reach rough consensus on a single best approach.
>    Accordingly, the recommendation has been left to the co-chairs. 

This portrays the failure to achieve consensus as being of the group
- and implies that the group "left" the task to the co-chairs.

As noted in (msg06441) you never pursued the finalisation of an
agreed goals document (as required by the Charter) and you generally
discouraged or banned discussion of "proposals" (candidate
architectures), without contributing much in the way of whatever
"architectural" discussions you wanted us to engage in.

You let the matter of writing the Recommendation drift without any
statement of your plans, until, after some questions from me in late
March, you announced your intention not to seek consensus, and to
write the Recommendation with Lixia.

If you want to strengthen your account of the background against the
inevitable criticisms, you might like to write something along the
lines that you tried to restrict discussion to whatever it was you
considered "architectural", and that you did not pursue the extended
discussion of, or the finalisation of, a "goals" document.

You might then explain why you did this.  I can't imagine a valid
justification, but you can.  You might like to explain when and why
you took this decision not to seek consensus.

However, in your defence, it should not be assumed that you and Lixia
were exactly thrilled at being given the task of co-chairing the RRG
and guiding a self-selected group towards discussion and consensus on
this very difficult problem.  Furthermore, while people complain
about you two taking it upon yourselves to write a Recommendation,
without seeking consensus, there is, so far, at this very late stage,
an extraordinary lack of action among most RRG participants in terms
of critiquing proposals other than their own and in terms of writing
what they would like to see in a comprehensively argued Recommendation.


>    The
>    remainder of this section describes the rationale and decision of the
>    co-chairs, and does not reflect the consensus of the group.

OK.

>    As a reminder, the goal of the research group was to develop a
>    recommendation for an approach to a routing and addressing
>    architecture for the Internet.  The primary goal of the architecture
>    is to provide improved scalability.

Yes - but "scalability" is just a single word.  I think it is vital
that you explain your understanding of the goals, such as:

   IPv4 vs. IPv6.  One or the other first, or not bother with IPv4?
   This involves questions of how long IPv4 will be used for, and
   what costs there will be if its scaling problems are not solved.

   Portability vs. expecting networks to renumber when they choose
   another ISP.

   Coping with the continued (highly constrained) rate of growth in
   multihomed end-user networks vs. allowing a much greater rate of
   growth (to better match the needs of end-user networks) in a
   scalable manner.

   Having the architectural enhancement directly facilitate mobility
   or not.

   To what extent it is justifiable to burden all hosts with extra
   processing, extra communications and extra delays when
   establishing a communications session in order to achieve scalable
   routing (however defined) without adding much, or anything, to the
   network itself.


> 17.1.  Motivation
> 
>    Without a new routing and addressing architecture, there is a concern
>    that the cost and structure of the routing architecture as we know it
>    today would become prohibitively expensive, with repercussions to the
>    overall growth of the Internet.  We need to avoid this and must thus
>    select some solution and push forward with it.
> 
>    For the long term future of the Internet, it has become apparent that
>    IPv6 is going to play a signficant role.  It has taken more than a
>    decade, but IPv6 is starting to see some non-trivial amount of
>    deployment.  This is in part due to the runout of IPv4 addresses.  

I suggest you cite some of these "non-trivial" deployments.  I can't
think of any - and I guess many readers would have the same difficulty.


>    It
>    therefore seems apparent that the new architecture must be applicable
>    to IPv6.  It may or may not be applicable to IPv4, but not addressing
>    the IPv6 portion of the network would simply lead to recreating the
>    routing scalability problem in the IPv6 domain.

With this, you simply skip over the problem of solving the only
current or near-term routing scaling problem: IPv4's.  I think most
readers will recognise this avoidance and so regard your
recommendation with increased suspicion.


>    Whatever change we make, we should expect that this is a very long-
>    lived change.  The routing architecture of the entire Internet is a
>    complex, expensive subsystem, and permanent, pervasive changes to it
>    will require difficult choices during deployment and integration.
>    These cannot be undertaken lightly.

OK.

But if long-term always trumps problems with introduction, we would
all change to a Dvorak keyboard and all countries in the world would
standardise on driving on one side of the road.

You have failed to mention that architectural changes can only be
adopted voluntarily, and that there are considerable constraints on
this form of adoption, when it is considered that very high adoption
rates are required to solve the scalability problem.

In the case of ILNP or any other CEE architecture, you need to have
100% (or close to 100%) adoption before any adopter gains proper
benefits (being able to rely on the new system for all their traffic)
and before you can gain substantial scaling benefits.  These
constraints don't apply to CES architectures, which can provide
immediate full benefits to adopters, and routing scaling benefits in
direct proportion to levels of adoption.

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

IPv6 is a great idea in many ways.  If not for constraints such as
these, it might have been very widely adopted in recent years.

To ignore these constraints would probably doom your recommended path
of action to the same extended and potentially permanent Limbo that
IPv6 languishes in.


>    By extension, if we are going to the trouble, pain, and expense of
>    making major architectural changes, it follows that we want to make
>    the best change possible.  

Yes - but what is "best", when the host-based (CEE = Locator
/Identifier Separation) architectures add to host complexity, delays
and traffic requirements?  This is particularly significant since in
the foreseeable future, I think it is reasonable to expect most hosts
will be hand-held devices hanging off a tenuous 3G or similar
wireless link, with their operation fundamentally constrained by the
limits of their batteries.


>    We should regard any such changes as
>    permanent and we should therefore aim for long term solutions that
>    position the network in the best possible position for ongoing
>    growth.  Our goal should be to make permanent, long-term changes to
>    the architecture and those changes should be smoothly integrated,
>    first-class citizens within the architecture.

OK.


>    Over the history of the Internet, we have been very good about
>    creating temporary, ad-hoc changes, both to the routing architecture
>    and aspects of the network layer.  However, many of these band-aid
>    solutions have come with a significant overhead in terms of long-term
>    maintenance and architectural complexity.  This is to be avoided and
>    short-term improvements should be replaced by long-term, permanent
>    solutions.

OK.

The IETF has also had a spectacular failure in proposing IPv6 as if
the barriers to widespread adoption were far less than are actually
the case.


>    In the particular instance of the routing and addressing architecture
>    today, we feel that both short-term improvements and long-term
>    solutions are worthwhile.  These are not incompatible specifically
>    because we truly intend short-term improvements to be completely
>    localized and temporary.  As the long-term solution is rolled out and
>    gains traction, the short-term improvements should be of less benefit
>    and can subsequently be withdrawn.
> 
> 17.2.  Recommendation to the IETF
> 
>    On behalf of the routing research group, the co-chairs would like to
>    recommend that the IETF pursue work in the following areas:

I suggest you change this to:

     The co-chairs recommend that the IETF pursue work in the
     following areas:


>       Aggregation in Increasing Scopes [I-D.zhang-evolution]
> 
>       Identifier/Locator Network Protocol (ILNP) [ILNP Site]
> 
>       Renumbering [I-D.carpenter-renum-needs-work]
> 
> 17.3.  Rationale
> 
>    We selected Aggregation in Increasing Scopes because it is a short-
>    term improvement.  It can be applied on a per-domain basis, under
>    local administration and has immediate effect.  While there is some
>    complexity involved, we feel that this is option is constructive for
>    those who find the additional complexity to be less painful than
>    upgrading hardware.
> 
>    We recommended ILNP because we find it to be a clean solution for the
>    architecture.  It separates location from identity in a clear,
>    straightforward way that is consistent with the remainder of the
>    Internet architecture and makes both first-class citizens.  Unlike
>    the many map-and-encap proposals, there are no complications due to
>    tunneling, indirection, or semantics that shift over the lifetime of
>    a packets delivery.
> 
>    We recommend further work on automating renumbering because even with
>    ILNP, the ability of a domain to change its locators at minimal cost
>    is fundamentally necessary.  No routing architecture will be able to
>    scale without some form of abstraction, and domains that change their
>    point of attachment must fundamentally be prepared to change their
>    locators in line with this abstraction.

I listed my primary objections to these in (msg06441).

I think you should acknowledge that ILNP:

  1 - Can't help with IPv4.

  2 - Requires all hosts adopt IPv6 and then adopt the ILNP changes
      to IPv6.

  3 - Is in a very early stage of development.

  4 - Is one of four CEE (Locator / Identifier Separation) proposals
      - and you have not explained why it was chosen over the others.

  5 - Involves extra processing, extra packets and typically extra
      delays in establishing initial communications.

  6 - Can't support certain important functions which are done today
      such as ACLs based on IP addresses.

I think you should also note that "Renumbering" is not an RRG
proposal, and that the author of the I-D you cite - Brian Carpenter -
recently (msg06470) wrote that his I-D is a problem-statement and
gap-analysis, not a solution.

 - Robin