Subject: Re: [rrg] Next pass

From: Ran Atkinson <[email-masked]>
Date: Fri, 23 Apr 2010 12:46:13 -0400

Two comments, both editorial...

Part of the draft language tli posted was:
> The remainder of this section describes the rationale and
> decision of the co-chairs, and does not reflect the consensus of the group.

1) The sentence above can be parsed in more than one way.

  I think the intended meaning of the last dependent clause
  is actually that "the RG had no rough consensus on a
  specific recommendation" rather than "the RG had a rough
  consensus and the RG Chairs ignored that consensus".

  So I'd suggest splitting the original sentence above into 2
  distinct sentences.  Candidate text (edit to taste):

	The remainder of this section describes the rationale
	and decision of the co-chairs.  The RG itself was
	not able to reach consensus on specifics of a
	recommendation.

  To the extent the RG Chairs' recommendations align with
  the recommendations at the end of RFC-4984, at least in
  terms of topics addressed by the recommendations, that 
  would seem worth noting.

2) More General RG Consensus

  Noting that "rough consensus" is very different from unanimity,
  I *believe* (could be wrong) that there were a small number
  of conceptual things that the RG did achieve rough consensus 
  on.  I'd like to see those noted as RG consensus items in
  the Recommendation document.

  I think one of those rough consensus items is:
     The Internet continuing down the current architectural path,
     whereby site multi-homing increases the size/entropy of the 
     DFZ RIB/FIB is not believed to be scalable or viable.

  I think another comes from RFC-4984, specifically from 7.2,
  which suggests some form of ID/Locator split is desirable.

  (NB: While the RG does not agree on the details of how that split
  best should happen, there appears to be rough consensus within
  the RG that some form of ID/Locator split is desirable.)

Yours,

Ran

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Apr 2010 20:23:05 +0200

Ran,
>    the Recommendation document.

+1.

>       DFZ RIB/FIB is not believed to be scalable or viable.

+.98.  Perhaps I would write it slightly differently.

      The Internet continuing down the current architectural path,
      whereby site multi-homing increases the size/entropy of the
      DFZ RIB/FIB exposes operators to risks of unpredictable
      growth in associated costs.

This takes into account Geoff's latest observations and analysis with 
regard to table growth.  I don't think we can say at this point whether 
things have momentarily leveled off, or whether we are seeing a sort of 
plateau, based on current usage patterns.

I think there is a related point to capture:

    The limits of scaling we see today have led us to impose limits on growth
    such as making multihoming far more the exception rather than the rule
    and hence limiting means of resiliency.  Further, those few consumers who
    want to multihome must either pay an inordinate fee for the service, or
    must make use of NATs that pose their own sets of problems.

>    the RG that some form of ID/Locator split is desirable.)

+1.

Eliot

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Apr 2010 20:58:22 +1000

Hi Ran and Eliot,

+1.

>      growth in associated costs.

+1 for Eliot's revised version.  However, we should probably also add
something about concerns regarding less stability, longer convergence
times and perhaps security in the interdomain routing system (DFZ).

+1.

Does this sufficiently capture our belief (I think we all believe it)
that the number of networks with multihoming (portability and TE
too?) today is much smaller than the number which would, ideally,
have it?  I think most or all of us believe a scalability solution
should not only cope with growth in multihoming with the current
constraints and costs, but should also greatly reduce those
constraints and costs to allow many more networks to do it?

>>   the RG that some form of ID/Locator split is desirable.)

Please see my recent message "Separating location and identity - what
does this mean?".

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 24 Apr 2010 11:50:58 -0700

> plateau, based on current usage patterns.

I suggest that folks look at Geoff's numbers for IPv6.  They show that in
2009, there was 54% growth in prefixes.  Consider the implications of that,
compounded.

Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 24 Apr 2010 12:17:46 -0700

Hi Ran,

> not able to reach consensus on specifics of a

Thanks.  I'm happy with that if we can swap the ordering of the sentences.
Can other folks live with that?

>   the Recommendation document.

As noted elsewhere, I don't have the bandwidth right now for that.  I would
welcome other folks proposing text and polling for consensus.

Tony