Subject: WG next steps

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Nov 2002 12:26:09 -0500

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 19:07:51 +0100 (CET)

> Thoughts?

I have no thoughts on the requirements.

About the roadmap: I think it would be useful at this stage for people
to write up their ideas as drafts. I think the wg membership is
competent enough to find the most significant weak points in each
proposal. If all of this is documented, we can simply arange the pieces
in such a way that the least amount of space remains uncovered by a
solution and then come up with the glue to hold it all together and
start fleshing out the solutions.

Iljitsch

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 13 Nov 2002 13:13:12 -0500

On Wednesday, Nov 13, 2002, at 12:26 America/Montreal, Thomas Narten 
>   doc to make reference to.

A reasonable approach to the above situation would be for the IAB
to create a new IRTF Research Group on the topic to permit such
architectural work to be done holistically.  The output of such a group 
would,
of course, need to be brought back to the IETF for consideration
before it could become any sort of standard.

I believe the IAB would look favourably on such a proposal to create an
IRTF RG, if a proposal were presented in a well organised manner.
The proposal would have to be sufficiently different from the NSRG,
which examined an overlapping set of issues, of course.

>   revalidate that it continues to make sense to keep working in a

See above.

Note that running code could be developed inside or outside the IETF.
Having running code might help persuade folks that a proposed approach
is viable.  Experimental computer science is a fine thing here.

Ran
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Nov 2002 11:52:58 -0800

> before it could become any sort of standard.

I think we tried that.  What makes this time different?

---

From: "Michael H. Lambert" <[email-masked]>
Date: Wed, 13 Nov 2002 15:10:41 -0500

>   costs upon different parts of the elements and entities that the

Yes!  It is not obvious that a single, monolithic, globally-optimal 
solution is going to present itself before a (partial, at least) solution 
must exist.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Nov 2002 20:26:37 +0000

> solution is going to present itself before a (partial, at least) solution 

Most definitely.  Talk of a single solution is optimistic at best.  It
would be like there being only one transition tool in v6ops...

Tim