Hi Tony,

You wrote:

>> OK - but where have you encouraged debate, or contributed to it by
>> arguing for your own preferred position?
> Well Robin, I have to admit, I've been far less prolific than you have been.
> However, for the last three years, I've been plugging away for an
> enlightened debate about the solution space.  No takers. 

Maybe your vision of an enlightened debate doesn't accord with that
of others.  I have been trying to do the same thing and it seems you
and I rarely agree about how to discuss things or about how to solve
the routing scaling problem.  Other people appreciate my efforts to
understand and discuss their proposals - so maybe my idea of how to
debate things is shared more by other people than yours is.

> I've argued for my position in the past and been slammed with
> ~"that can't possibly work"~

Core-Edge Separation AKA Locator / Identity Separation could work,
but only if:

  1 - Everyone moved to IPv6 services, network addresses, routers,
      hosts and applications.

  2 - Essentially all IPv6 hosts stacks are upgraded.  (Some CEE
      architectures require upgraded applications.  I understand
      ILNP doesn't.)

  3 - Upgrade any routers which need it.  (For ILNP I understand
      routers rewriting Locators is optional.  I am not sure how
      important it would be to have this.)

Considering there are Core-Edge Separation alternatives such as LISP
and Ivip which work for IPv4 and IPv6, and don't require changes to
any hosts or most routers, then I agree with the critiques you have

Can you point to mailing list messages or other materials in which
you argued that it could work and that this would be superior to a
CES architecture?  I think this would involve justifying the extra
host burdens and delays of the CEE approach in terms of the reduced
complexity of the routing system and potentially other benefits.

>> I understand you support
>> ILNP (CEE, Locator / Identity Separation) - which are only practical
>> for IPv6.  I am not sure what you want for IPv4.
> I want nothing.  IPv4 is done.  Over.  Cooked. Fully toast.  It will either
> enter a black market where we deaggregate and no proposal will help, or we
> shift to v6 and v4 is irrelevant.  In either case, we're not in time to do
> anything significant for v4.  And we still need a v6 solution, that's
> clearly higher priority.

The IPv6 Internet could be unplugged right now and almost no-one
would notice.  All the work, all the pleasure, all the social contact
which occurs on "The Internet" as people know it today would still
happen without a glitch, because the IPv4 Internet is the only one
essentially everyone uses and relies upon.

In the thread:

   IPv4 & IPv6 routing scaling problems

a number of people indicated that they considered IPv4 important and
that it was going to be used for a "long time".

LISP or Ivip will allow better utilization of IPv4 address space, in
a scalable manner, as I argue in:


     17.2.3 and 17.5 para 3.

I am curious to know Lixia's view on this.  If one or both co-chairs
don't see IPv4 as in need of a solution, while many other
participants do, then I hope you will try to respect the wishes of
what may AFAIK be the majority of participants who want to devise and
ideally reach consensus on the best approach to solving the IPv4
routing scaling problem as well as IPv6's.  I believe the IPv4
problem is more urgently in need of fixing than IPv6's - and my guess
is that quite a number of other people agree.

Its not just portability, multihoming and inbound TE for fixed
end-user networks.  Mobility is also part of what needs to be done
scalably.  Mobility is prominently mentioned in the RRG Charter, and
the Charter contains nothing to indicate that the IPv4 scaling
problem is either insoluble or less urgent than any scaling problem
IPv6 may have in the future.

>> Since you are one of the co-chairs and you are urging us - indeed
>> expecting us - by so-far unspecified methods, to develop and in some
>> way be happy with a single-architecture Recommendation in the next 19
>> days, I was hoping you would be able to give us more guidance about
>> how to debate this, including leading by example: by arguing in
>> detail for your own preferred outcomes.  Lixia has done this for her
>> AIS (Evolution) proposal.
> I'm not expecting anyone to develop a recommendation.  I'm not expecting
> anyone to be happy with it.

Does this mean you are going to develop the recommendation?

>> You haven't yet stated when you and Lixia intend to finalise the text
>> of the RRG Report, at which point you will choose what, if anything,
>> goes in the Recommendation section.  Nor have you explained how you
>> will choose the text, or guide the mailing list or meeting discussions.
> We will present the results at our next meeting.  After that, we will polish
> the text and then publish the final document.  We will certainly be happy to
> take input on the text, but we will not promise to incorporate any of it.

My interpretation of this is that you and Lixia will write the
recommendation and while you will read or listen to what people have
to say about it, you won't promise to take notice of any of it or to
alter your text according to the views expressed by RRG participants.

In the past, you have stated your intention to achieve consensus on a
recommendation.  Now I understand you don't intend to achieve or even
test for consensus on the recommendation you and Lixia will prepare.

>> Do you intend to finalise the Recommendation during the meeting, or
>> afterwards?  If the former, than I am concerned that those not at the
>> meeting will be at a disadvantage through not being able to be
>> express our arguments as directly as those who can attend.  If the
>> latter, do you have any plans for how long after the meeting you will
>> finalise the text?
> Again, finalizing the text will be later.  Yes, regardless, you're at a
> disadvantage being remote.  Sorry, but the IRTF (unlike the IETF) has no
> constraints about the mailing list being the primary mode of operation.  

OK.  http://tools.ietf.org/html/rfc2014

    Since the products are research results, not Internet standards,
    consensus of the group is not required.  Rather, the measure of
    success is the quality and impact of the research results.


    A Research Group will conduct much of its business via its
    electronic mail distribution list(s).  It is also likely to meet
    periodically to accomplish those things that are better achieved
    in more interactive meetings, such as brainstorming, heated
    altercations, etc.  Meetings may be scheduled as telephone
    conference, video teleconference, or face-to-face (physical)


    Each Research Group will determine the balance of email and
    face-to-face meetings that is appropriate for making progress on
    its goals.


    The challenge to managing Research Group meetings is to balance
    the need for consideration of the various issues, opinions and
    approaches against the need to allow forward progress.  The
    Research Group, as a whole, has the final responsibility for
    striking this balance.


    It is up to the Research Group to decide the authorship of papers
    resulting from Research Group activities.  In particular,
    authorship by the entire group is not required.


    The Research Group Chair is concerned with making forward
    progress in the areas under investigation, and has wide
    discretion in the conduct of Research Group business.  The Chair
    must ensure that a number of tasks are performed, either directly
    or by others assigned to the tasks.

The statements above give responsibilities to the "Research Group" -
however, the following items indicate the Chair has ultimate
responsibility for deciding how the "Research Group" works:

    The Chair has ultimate responsibility for ensuring that a
    Research Group achieves forward progress.

There's no mention of consensus being required, or of the Chair being
responsible for doing things the way any one or more participants

> Nor
> are there requirements for us to do anything to support remote
> participation.  We do try to, but that's mostly thanks to co-location with


>> This is a statement about the past.  If this continues for the next
>> few weeks, then there will be no large enough subset of active RRG
>> participants with a compatible opinion to form anything like
>> consensus.  But I doubt that everyone would hold to their own
>> proposals in the context of a detailed, constructive, debate - a
>> debate we are yet to have.
> Again, we've been trying to have that debate for three years.

I believe you have not contributed much to the debate.

You banned debate about "proposals" for most of the time since 2007.
 (I will provide links to the messages if anyone wants them.)  You
required all people with proposals to submit "Summary and Analysis"
documents in early 2008 - which you and Lixia never commented on or
encouraged debate about.   If your ban and discouragement had been
universally respected, then there would have been much less debate of
any kind - and in my view less progress.

You frequently requested we debate "architectures" - as if this was
somehow different from proposals.  Yet I don't recall an instance of
you leading by example with any such messages.

The CEE / CES distinction is the single biggest architectural
distinction I know of between the various potential solutions.  You
say it isn't significant or helpful, but you don't say why you
believe this - such as by why you disagree with msg05865.

>> OK - but if you and Lixia include text as a "Recommendation" without
>> a process which tests support for it - or if there is such a test and
>> it only gets minority support - then the "Recommendation" won't have
>> much value or be taken particularly seriously by the IESG or anyone else.
> Again, the IRTF is not bound by a consensus process.  In the preceding years
> where we've tried to drive consensus, we've gotten no response.  

I think you have done little or nothing to achieve consensus.  Lixia
at least has participated in a proposal - APT and now AIS
(Evolution).  I understand you support ILNP.  On another mailing list
(arin-ppml/2008-June/010988.html) you stated how important GSE was.

I don't recall where you argued that the extra burdens on hosts and
delays in communications was either insignificant or worth the saving
in routing system complexity.

You haven't critiqued any of the proposals - but Lixia did.

I don't think you have done much to find commonalities and points of
disagreement between participants.  Lixia as done something towards
this by discussing a taxonomy in the past.  She also was co-author of
the paper which did most to establish Core-Edge Separation and
Core-Edge Elimination as valuable terms in this field.

I think you have neither supported the kind of debate which might
result in greater consensus nor debated anything in a manner which
shows by example how to constructively debate the merits of a
proposal, architecture or whatever.

> We're left
> making a call without consensus.  If that means that it doesn't have broad
> support, well, so be it.  We committed to a deliverable and we're going to
> see it through.

OK - you are the co-chairs.

I am surprised you are planning on writing the Recommendation rather
than working with others to do so.  I guess other folks would be
surprised too.

>> I don't recall you or Lixia write anything about what various groups
>> of people have in common and where they differ.
> That's because we would never reach consensus on what _that_ text would be
> either.

I don't see how you could be sure of this if you haven't tried.

>> Sure - but if that is the best we can do, then surely it would be
>> better to produce a coherent report on the various positions which
>> people have adopted, with the arguments each group advances in
>> support of their position, and the arguments they provide against the
>> positions of others.
> Done.

I agree.  If nothing further happened the recent process of
proposals, critiques and "rebuttals" has been constructive and I
believe of lasting value.  I intend to write up an ID containing, or
pointing to, the fuller discussions about each proposal, including
critiques which didn't make it into the final RRG Report.

>> To pretend that the situation involved more agreement than it really
>> does would be a worse failure.
> No one is claiming agreement.

OK.  So what you seem to be planning is the co-chairs writing a
Recommendation and everyone else discussing it, with no guarantee
that the co-chairs will use that discussion to alter the Recommendation.

I think the result of that won't have anywhere near as much influence
on the thoughts of people outside the RRG than a Recommendation which
resulted from more engagement and input from the group itself.

This is especially the case regarding the IPv4 routing scaling
problem, which you have indicated you have no interest at all in
trying to help with.

Those people will at least be able to see a bunch of proposals, the
frequently artificially shortened critiques and "rebuttals" and then
look into the RRG archives to see more substantial material and what
other folks had in mind about the best way to solve the routing
scaling problem, including with mass-adoption mobility.

  - Robin

rrg mailing list

Reply via email to