WG next steps

[Thomas Narten <narten@us.ibm.com>]

Note: chair hat on. Sean and I are largely in sync on the issues in
this note.

There has been a lot of discussion recently, including some specific
solution directions. That is good.

We also have two documents we need to finish, but have had difficulty
coming to closure. That is not good.

If we go back to our original charter, it includes the following:

> The WG will take on the following initial tasks:
> 
> Produce a document defining what site multihoming is, the requirements
> for a multihoming solution (from both the end site and ISP
> perspective).  This document will also include a taxonomy of different
> ways that multihoming might be achieved.

We have a requirements document, but various people have expressed
their concern that it has seemingly contradictory requirements, or is
too vague on important points.

There are also some saying we should just ship it (with tweaks to
further water down the content), in order to move to the next
step. That begs the question: what is the next step, and will it
be helped by just shipping the current documents as is?

The IETF has had mixed results from requirements documents, so I think
its useful to try and see how requirements-type documents are used in
the IETF and how we might make use of one: Possibilities:

- requirements that MUST/MAY/SHOULD be satisfied. I don't see that as
  being so useful here, because it is unclear we could develop a
  single solution that satisfies them all anyway. Plus, having a bunch
  of SHOULDs often turns out to be a wish list of things that can't be
  delivered. 

- an exercise that the WG uses to better understand the underlying
  issues. Clearly this document has triggered a great deal of
  discussion about a large number of these issues, but it doesn't mean
  that the document itself will necessarily be useful as an RFC. I.e,
  the goal isn't necessarily the document itself, it's the process of
  discussing it that is important.

- Development of a set of desirable goals/properties. It may well be
  that not all can be satisfied, but having a list would make it
  easier to look at a specific proposals (or possible work directions)
  and see which  criteria they might meet and which they
  cannot.

Personally, I think the latter type of document makes the most sense
for this WG. We will need a way of comparing and contrasting different
approaches as part of deciding what their pros and cons are.
  
More charter text:

> Produce a document describing how multihoming is done today, including
> an explanation of both the advantages and limitations of the
> approaches.
> 
> The WG will also consider specific proposals to multihoming in IPv6
> (both existing and new) and select a small number of them to work on
> as formal WG items. Development of specific solutions will require
> approval of the IESG (e.g., a recharter).

We have some proposals, but none have them have been made WG
documents.  I sense that there is a desire (at least from some) that
we should just move towards developing solutions. However, I fear that
without some sort of structure or roadmap for how we will consider,
develop and evaluate proposals -- or even which general directions
would be fruitful to do more work in -- followup work will at best be
chaotic.  I think we need a process for deciding which general
directions we want to focus on and a roadmap for the steps to take as
we look at different directions. We need a process/roadmap because:

- we (as a group) have limited resources and will want to concentrate
  efforts in those areas most likely to be beneficial.

- Some of the proposals on the table involve fairly significant
  architectural changes to the Internet protocols. But this WG does
  not have a mandate to, for example, go modify TCP. If we are to work
  on solutions that place signficant requirements on other WGs, we'll
  need the cooperation of other areas and WGs. One of the things that
  will help getting that cooperation is that these proposals satisfy
  the multihoming needs we (as a group) believe exist today and into
  the future, and (perhaps) that proposals which do not involve these
  changes do not.  For that we likely do need a proper, reviewed reqs
  doc to make reference to.

- We may want to consider multiple, complementary, and non mutually
  exclusive approaches to IPv6 multihoming, if we conclude that
  different approaches serve different sets of interests, or impose
  costs upon different parts of the elements and entities that the
  Internet comprises.

- it is not even clear whether this WG (as a single WG) is the best
  place to develop solutions for any or all the approaches worth
  considering. Note that our charter states that we will be
  rechartered prior to developing solutions. So I think we need to
  focus on developing a roadmap that allows us to make a strong case
  for why we (or the IETF) should work on a particular
  direction/solution. 

- some of the possible directions need qite a bit more fleshing out,
  before folk can really begin to evaluation whether the direction
  makes sense. While early proponents surely believe it is obvious to
  produce work in a particular space, we will need signficant
  community buy-in if we are to actually succeed in deploying
  things. The more complex the proposal, or the more changes that are
  required to implementations to make them work (especially if they
  involve upgrades in *all* IPv6 devices!), the more work it will be
  convincing the relevant communities to support the changes. Thus, we
  need a way of starting work in some directions, but also have clear
  checkpoints that will allow us to assess progress and periodically
  revalidate that it continues to make sense to keep working in a
  particular direction.

- Any plan will need to include a transition plan that describes how
  we can get it deployed, and what sort of staging is needed. We are
  past the point of being able to say "its early in the process and we
  can modify all IPv6 nodes, so just do it". A real plan will need to
  take into consideration likely time frames for getting things
  specified as standards (i.e., in published RFCs), get implemented
  (by those devices that need to) and then deployed in sufficient
  numbers to obtain critical mass.

In summary, I think this WG needs to:

- finish work on the requirements document, and get a document we can
  use in evaluating and comparing possible approaches.

- develop a roadmap for how we are going to select possible areas to
  work on, and how work needs to proceed in each area in order to
  ensure that we have (and continues to have) the necessary concensus
  for the work from the constituancies that will be impacted and will
  need to implement any changes.

Thoughts?  
  
Thomas