Subject: [RRG] Conceptual vs. specific - another discussion list?

From: Robin Whittle <[email-masked]>
Date: Fri, 13 Jun 2008 20:16:36 +1000

I understand that for now, the co-chairs are directing the RRG
towards more conceptual discussion of the design space, without
specific engineering details, particularly of potential solutions.

I don't have much to contribute in that regard, because I can't
constructively think about various forks in the road without going
down each fork as far as I can, finding potential solutions and
discussing them in as much engineering and deployment detail as
possible.  Other folks are keen to engage in this sort of thing too,
but we need to do it without disrupting the high-level only discussions.

I have a bunch of RRG messages to read and respond to - probably
next week.  But my responses would probably fall outside the scope
of this "high-level only" conceptual discussion of the design space.

If such messages are not appropriate for this list at present, can
someone suggest an alternative?  Routing Research Gory Details
perhaps?  Routing Research, Engineering and Deployment?

I could run a list with public web archives myself, but it might be
better if someone not so involved in the discussions ran the list.
A list under the IETF or IRTF banner would probably be best.

Should we continue the discussions which don't suit the RRG on the
RAM list?

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Robin Whittle <[email-masked]>
Date: Sat, 14 Jun 2008 14:01:44 +1000

My first message in this thread concerned moving one set of
discussions to another list, such as the RAM list or some newly
created one:

  Discussion about the architecture which involved too much
  focus on potential solutions - particularly the engineering and
  deployment details - to be compatible with the current scope of
  the RRG list.

Now there are some other lines of discussion which might be
inappropriate for the RRG list, due to the rough consensus reached on:

   Our recommendation should be applicable to IPv6.  It may or
   may not also apply to IPv4, but at the very least must provide
   a path forward for IPv6.

  http://psg.com/lists/rrg/2008/msg01417.html    2008-06-06
  http://psg.com/lists/rrg/2008/msg01535.html    2008-06-13

Lixia and Tony, does this mean that it would be out of scope to have
even high-level architectural discussions concerning a potential
solution which would be applied soon to IPv4 and later to IPv6?

Likewise, does this mean that discussions about migration of large
numbers of users to IPv6, or to a future significantly modified
version of IPv6, are out of scope?  My guess is they would be, and
would disrupt the discussions you want to focus on.

Can you clarify the scope of the RRG discussions, including with
some examples?  I have a feeling that quite a lot of recent threads
which I and others want to continue to discuss are outside the RRG
scope, which you alone decide.

Is it possible for you to organise a separate IRTF discussion list
and appoint someone to moderate it?  I guess you don't want to be
responsible for two lists.

I think the scope of the RRG list you want for now - and perhaps
until 2009-03 - is narrower than the full scope of the RRG charter:

   The RRG will have an open general discussion mailing list where
   any topic of interest to the routing research community can be
   discussed, and topics related to scalable routing architectures
   are particularly encouraged.

Some people interpret "research" as not involving engineering.
However, this is an engineering field.  This is not science, such as
astronomy or biology, which are concerned purely with understanding
the processes of Nature.

This is research into network engineering - prior to the engineering
task of the IETF creating final protocols, standards etc. to
implement a specified architecture.

I understand you need to restrict the scope of the RRG list to make
the progress you aim for.  Other discussions can take place
according to the next part of the Charter:

   For specific topics with widespread discussion, interested
   parties will be encouraged to form ad-hoc mailing lists, with
   summaries sent to the general mailing list quarterly. Summaries
   will contain the recent conclusions reached as well as the
   near-term agenda for future progress.

Some RRG-related matters are being discussed now on ARIN-PPML.  See
below my signature for two examples.

However, I think PPML is not the best place to continue the routing
and addressing architecture discussions which don't belong on the
RRG list.

Do you suggest the RAM list be used for this?

If not, maybe someone can set up a list with public archives.

In mid-July I could set up Mailman and an archive on
www.firstpr.com.au (the server is in Dallas - Fort Worth) or I could
create a separate domain for it, such as: radiscuss.net

It would probably be better if the list was run by someone else -
someone not so directly involved in the discussions - since that
person needs to make the final judgement about what was on topic,
what was reasonable or a flame etc.  Also, an IRTF list would
probably have a more permanent archive.

There is always Yahoo Groups, but that is ad-infested and not
necessarily a secure or easy to use archive.  The first message from
each member needs to be held for moderator approval to prevent spam.

  - Robin

Recent PPML discussions:

  http://lists.arin.net/pipermail/arin-ppml/

     Alain Durand's Comcast "464" plans are of interest to the
     question of adoption of IPv6-only services, which I think the
     RRG rough consensus involves some assumptions about.  464
     uses the IPv6 access network to tunnel IPv4 packets to a
     special kind of NAT.  The result is each customer gets their
     own private IPv4 address space (such as 192.168/16) and has a
     single layer of NAT in the remote NAT box.  Manual port
     forwarding cannot be supported, so uPnP IGD can't be used -
     with consequent impact on P2P and probably other apps.
     So this would not really be an IPv6-only service - for most
     users it would be a NATed IPv4 service like what they get now,
     but without the possibility of grabbing a port to receive
     packets from a stable public IPv4 address.

     Also, several folks on PPML with long experience support the
     statement which we have just formed rough consensus on.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 13 Jun 2008 22:44:57 -0700

Hi Robin,

|   Our recommendation should be applicable to IPv6.  It may or
|   may not also apply to IPv4, but at the very least must provide
|   a path forward for IPv6.
|
|Lixia and Tony, does this mean that it would be out of scope to have
|even high-level architectural discussions concerning a potential
|solution which would be applied soon to IPv4 and later to IPv6?

Not at all.  As we stated, solutions that apply for v4 and v6 are certainly
within scope.

|Likewise, does this mean that discussions about migration of large
|numbers of users to IPv6, or to a future significantly modified
|version of IPv6, are out of scope?  My guess is they would be, and
|would disrupt the discussions you want to focus on.

Yes, you're correct.  We've spent 15 years talking about v6 migration and
there's been very little light shed for the last 14 of those.  ;-)

|Can you clarify the scope of the RRG discussions, including with
|some examples?  I have a feeling that quite a lot of recent threads
|which I and others want to continue to discuss are outside the RRG
|scope, which you alone decide.
|
|Is it possible for you to organise a separate IRTF discussion list
|and appoint someone to moderate it?  I guess you don't want to be
|responsible for two lists.

I've got no problems moderating more lists and if folks want to spin off
subgroups to go have disucssions that's also welcome.  I'd like to know what
subjects/problems/projects/experiments they are going to deal with.

|I think the scope of the RRG list you want for now - and perhaps
|until 2009-03 - is narrower than the full scope of the RRG charter:
|
|   The RRG will have an open general discussion mailing list where
|   any topic of interest to the routing research community can be
|   discussed, and topics related to scalable routing architectures
|   are particularly encouraged.
|
|Some people interpret "research" as not involving engineering.
|However, this is an engineering field.  This is not science, such as
|astronomy or biology, which are concerned purely with understanding
|the processes of Nature.

I interpret research as simply broader than engineering.  Engineering is the
art of building based on the knowledge at hand.  Research also encompasses
pushing back the boundaries of knowledge.  

Since what we're doing is computer networking, which is largely based on
graph theory, complexity theory, computer scient, and topology, I'd say that
what we're doing is definitely applied mathematics.  Therefore it counts as
hard science.  I have to admit bias here, as I'm trained as a mathematician
and computer scientist.

|However, I think PPML is not the best place to continue the routing
|and addressing architecture discussions which don't belong on the
|RRG list.

Agreed.

|Do you suggest the RAM list be used for this?
|
|If not, maybe someone can set up a list with public archives.

It would be more appropriate if we set it up under the auspices of the IRTF.
We can easily do this.  Again, the mailing list should have a specific
purpose.  Please feel to collaborate with a few others to put together a
proposal.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 14 Jun 2008 22:47:12 +1000

Hi Tony,

Thanks very much for offering to set up another IRTF list.

I would like to keep this thread going to discuss the suggested
scope, charter or whatever.  If you don't want that, then I would
appreciate people writing to me offlist so I can coordinate their
desires into a proposal and send it to you directly.

You wrote, in part:

> Not at all.  As we stated, solutions that apply for v4 and v6 are
> certainly within scope.

OK, but I have two concerns:

  1 - You have several times tried to steer discussion away from
      specific proposals.

  2 - If the proponents of such solutions are primarily interested
      in applying their solution to IPv4 in a shorter time-scale
      than the RRG consensus view indicates is necessary (the new
      rough consensus indicates the RRG may decide no IPv4 solution
      is ever necessary) then this discussion will get in the way
      of the higher-level conceptual discussion I think you want
      the RRG to focus on.

>> Likewise, does this mean that discussions about migration of
>> large numbers of users to IPv6, or to a future significantly
>> modified version of IPv6, are out of scope?  My guess is they
>> would be, and would disrupt the discussions you want to focus
>> on.
> 
> Yes, you're correct.  We've spent 15 years talking about v6
> migration and there's been very little light shed for the last 14
> of those.  ;-)

OK.  Discussion of IPv6 migration strategies, IPv4 address
reclamation, time-frames for IPv4 meltdown and IPv6 blossoming etc.
is clearly off-topic for the RRG list, but would be appropriate on
the new list.

I think the folks who don't share every consensus view still have a
lot to contribute to the overall process of developing a new
Internet architecture - and would like to discuss this in close
association with the RRG.

> I've got no problems moderating more lists and if folks want to
> spin off subgroups to go have disucssions that's also welcome.
> I'd like to know what subjects/problems/projects/experiments they
> are going to deal with.

That is very generous.

> I interpret research as simply broader than engineering.
> Engineering is the art of building based on the knowledge at
> hand.  Research also encompasses pushing back the boundaries of
> knowledge.

I think "research" is developing new knowledge about the natural
world and/or human constructed systems. I have no problem with
thinking of our work as being research into engineering principles
and techniques.  This may involve new or existing scientific or
mathematical principles.

I think the goal is to artfully combine known and perhaps novel
mathematical and engineering techniques and principles in order to
create the optimal architecture.  However, we also need to think
about existing practice, commercial considerations, the needs of
end-users etc.  Otherwise, no-one will adopt what we devise.

> Since what we're doing is computer networking, which is largely
> based on graph theory, complexity theory, computer scient, and
> topology, I'd say that what we're doing is definitely applied
> mathematics.  Therefore it counts as hard science.  I have to
> admit bias here, as I'm trained as a mathematician and computer
> scientist.

Maybe some computer networking architectures suffered from too
little focus on mathematically purity and therefore couldn't scale
so well as to operate on a global scale.

Perhaps overdoing the mathematical focus to the exclusion of other
considerations could lead to an architecture which is insufficiently
backwards compatible with existing practice to be widely adopted.

Here is a rough proposal, written as if there are to be more than
one moderator (which I don't assume) and assuming that you are one
of those moderators.

  The new list might be called:

     RRG-Sandbox

  [RSB], [RRGS] or [RRGSB] might be the subject header - the shorter
  the better.

  Membership of RRG-Sandbox is expected to be a subset of the RRG
  membership.

  All actively posting RRG-Sandbox members are expected to do so
  in awareness of current and recent RRG discussions.

  RRG-only members are not expected to take an interest in
  RRG-Sandbox.

  RRG-Sandbox is not intended as a venue for forming consensus of
  any kind.  The question of RRG consensus is determined solely by
  the RRG Moderators based on RRG messages.

  The Moderators may direct an RRG-Sandbox thread to be continued on
  the RRG list - or an RRG thread to be continued on RRG-Sandbox.

  Relevant topics include:

     New and modified Internet architectures concerning
     scalable approaches to routing and addressing, for
     purposes including:

        Multihoming for end-user networks.

        Traffic engineering.

        Portability or other approaches to easing the
        switch to another ISP.

        Mobility of networks and single hosts.

        Any other purposes where the routing and addressing
        architecture might play a crucial role, including QoS,
        better security and spam reduction.

        Improving IPv4 address utilization.

     IPv4's future, including use of NAT and map-encap.

     IPv6 adoption, transition mechanisms and future development.

     Transition to IPv6 or to whatever other architecture the
     RRG might recommend.

     Future architectures potentially quite different from IPv4/6
     - provided they involve scalable multihoming, TE etc.

     General discussion of the above and related fields which
     do not fit within the scope of the RRG list, as determined
     by the Moderators.

     This includes discussion of low-level details of potential
     solutions, including nascent ones such as GSE for IPv6 -
     and any speculative theories and proposals.

  Alternative viewpoints to those compatible with the rough RRG
  consensus are welcome and list members may discuss solutions to
  the routing, addressing, future Internet architecture questions
  which differ in goals, principles, details and time-scales from
  those which would fall within the developing RRG consensus.

  Since the discussions may be diverse and hard to keep up with,
  participants are encouraged to post occasional "Summary: xxx"
  messages pointing out what has transpired and linking to the most
  significant messages in the archives.

  Only the Moderators may cross-post messages from one list to the
  other - such as perhaps the occasional "Summary: xxx" to the RRG
  list.

   - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jun 2008 13:43:48 -0700

Tony and others,

>there's been very little light shed for the last 14 of those.  ;-)

I believe that some of the barriers to migration have been
shortcomings of tunneling mechanisms that might be used in
a solution to IPv6 routing scaling. In particular, it is
widely acknowledged that in-the-network tunneling can lead
to silent failure modes due to limitations in both classical
path MTU discovery and in-the-network fragmentation.
Additionally, multicast capabilities for automatic tunnels
that would support routing scaling have been specified but
not widely implemented or used.

I have described the VET (draft-templin-autoconf-dhcp) and
SEAL (draft-templin-seal) mechansims in past messages to this
list as proposals that address many of these shortcomings. I
can now say that running Linux kernel code that implements
VET and SEAL in the particular use case of IPv6-in-IPv4
tunneling is available for download and experimentation at:

  http://osprey67.com/seal

There is a README at the site that gives a barebones overview
of how to build and run the code. Further details are available
in the Internet drafts. As experimentation is an important
element of the research process, I would welcome constructive
feedback from those who would be interested to test the code.

Again, this is in response to the assertion that little light
has been shed on the IPv6 migration over the past decade (and
longer), since these technologies do shed new light. Based on
ways forward, I believe these technologies may play an important
role in our efforts to address IPv6 routing scaling.

Fred L. Templin
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Sat, 21 Jun 2008 13:13:32 +1000

Hi Dan,

In:

 Consensus? End-user networks need their own portable address space
 http://psg.com/lists/rrg/2008/msg01585.html

You wrote, in part:

> The RRG has not yet been able to agree on what motivations are
> possible in the long term (have we even decided on the duration of
> this 'long term'?  1000 years?  50 years? 10 years?).  An example
> of this lack of agreement is that Bill Herrin just made arguments
> for the need for PI space due to some current operational
> practices.  Tony Li rebutted that these practices can change over
> time.  Is it safe to assume that any proposal requiring these
> changes must come with some reasoning that these changes will
> indeed occur over time?
>
> Robin suggests that instead of trying to develop a general driver
> constraint, we should recommend specific proposals and discuss
> them.  For any particular proposal, we know the changes proposed.
> We can argue about the feasibility of the changes and evaluate the
> proposal based on this as well as the proposal's effectiveness,
> security, etc.  However, Tony doesn't think this is a good course
> of action.

I think the RRG needs to decide on a time frame for a solution, and
on whether we are pursuing a single solution, or multiple parallel
streams of research.  If so, do we discuss all those streams on the
RRG list, or should there be one or more other lists?

Then, for any stream of research, there is the question you mention
of whether we focus on conceptual discussion, avoiding specific
proposals.  I understand the desire to see beyond current proposals
and to seek new ideas, but I am very much opposed to ruling out
discussion of all the juicy details by which actual IT systems sink
or swim.  Call it engineering or whatever - this is research in an
engineering field, and we need to think about every possible detail,
while also thinking about broad architectural principles and new
ways of approaching the problem.

In this message:

  Conceptual vs. specific - another discussion list?
  http://psg.com/lists/rrg/2008/msg01530.html

I proposed a second RRG-Sandbox list to carry a wide range of
RRG-related discussions which were outside the scope of the RRG
list, since I understand the need to exclude from RRG discussions
quite a range of things in order facilitate progress as Lixia and
Tony think is best.

I was also prompted by rough consensus being achieved on:

  http://psg.com/lists/rrg/2008/msg01535.html

which I think would make it difficult or impossible to discuss IPv4
at all on the RRG list.

In these two messages:

  3 potential consensus questions
  http://psg.com/lists/rrg/2008/msg01574.html

  Long term clean-slate only for the RRG?
  http://psg.com/lists/rrg/2008/msg01594.html

I suggest the RRG needs to decide ASAP whether we are pursuing
several lines of research or just one - and if so, which one.

  - Robin