[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG next steps
Note: chair hat on. Sean and I are largely in sync on the issues in
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
- 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
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
> 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
- 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
- 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
- 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.