[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt
On Fri, Oct 29, 2004 at 10:50:41AM +0200, Brian E Carpenter wrote:
>
> I would say that in the spirit of the draft, the question is
> something like
>
> Will the solution add or change actions during a site renumbering procedure?
Sure - prefix with "During a renumbering procedure undertaken without a
flag day, a site will be transiently multihomed. Will...."
Maybe something also like "During such a renumbering exercise, it is likely
that the procedure will require the original prefix to be deprecated as the
new prefix is introduced. The addition of the new prefix and the removal
of the old prefix are unlikely to happen simultaneously across the whole
site. Does your solution support such behaviour?"
A renumbering exercise differs in that there's an exit strategy with the
removal of the original prefix, i.e. Section 2 of
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt
applies to the introduction of multihoming in a site (2.2 could read
"Preparation to migrate to a multihomed environment" rather than
"Preparation for the renumbering process", for example), but for Baker's
specific text we would assume the multihoming solution *is* multiaddressing,
but if down the road we get a nice multihoming solution, then renumbering
might use that solution, and not multiaddressing.
Everything up to Section 2.5 could apply to migration to being multihomed,
so really what we need is the multihoming solution to support the steps
outlined in 2.6 ("Transition from use of the old prefix to the new prefix")
and 2.7 ("Removing the old prefix"), but because Baker's text is written
with multiaddressing in mind, the specifics may be different.
One other aspect this introduces that maybe isn't captured in the draft is
that a multihoming solution may often be applied across a whole site, but in
some cases only some nodes may be multihomed (e.g. if the secondary link
is "costly" in some way, and only critical nodes or applications should
utilise the secondary link?). Should the developer be asked if their
solution supports that? The draft doesn't state explicitly if it is
concerned with site or host multihoming.
Tim