Subject: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2004 00:16:23 +0200

It is proposed to forward
     draft-ietf-multi6-things-to-think-about-00.txt
to the IESG for approval as an Informational RFC

Any final comments must be sent to the WG list at [email-masked]
within two weeks, i.e. at the latest on November 3, 2004.

Thanks

   Brian Carpenter
   multi6 WG co-chair

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Oct 2004 12:26:58 +0300 (EEST)

> within two weeks, i.e. at the latest on November 3, 2004.

I don't think this is quite ready yet.  Comments below.

==> a couple of 'things to think about' have been lost in the
revision.  Has this been intentional?  At least:

2.3.3 Can your solution be aggregated and implemented site-wide?
2.3.4 Does your solution impact existing traffic engineering methods

I think these are rather important, even thought the latter is focused on
MPLS, when it should be focusing on BGP traffic engineering practices
instead.

2.  On the wire behavior

2.1  How will your solution solve the multihoming problem?

     That's why we're here.  Remember, a reference is fine.

==> this seems almost like asking, in an email context, 'how does your 
proposal solve the spam problem?'.  This question is not good, because 
I don't think we have sufficiently clearly defined what "the 
multihoming problem" really is (and some might even argue it's 
multiple different problems), and its unlikely that the solutions can 
even solve the whole problem.

This will cause folks to answer, "the solution provides connection
survivability, solving the multihoming problem" .. BUT THAT'S NOT
THE (WHOLE OF) MULTIHOMING PROBLEM!

It's difficult to say how this should be fixed.  One way might be trying to
precisely define what 'the multihoming problem' refers to.  One way would be
rewording the question so that the responder should try to describe which
multihoming problem(s) the responder thinks what the solution is solving,
and which not.  Reference to a list of multihoming problems would also be
OK, but I don't think there is a good document laying these out.

2.7  Can multihoming capabilities be negotiated end to end during a
      connection?

     If the proposal introduces additional overhead, can the information
     be somehow piggybacked on messages that are already used?  This would
     be useful in order to keep connection setup constant.  Please also
     indicate any drawbacks that might apply due to this piggybacking.

==> I already proposed the following new section in March:

===
2.X Can multihoming setup be delayed from session setup?

If the proposal induces overhead (added bytes in packets, or
additional packets), is it possible to delay that overhead (or
"multihoming set-up") to happen after the session has been
established?

That is, is it possible to specify that multihoming benefits would
only be achieved for sessions which last over XX seconds, to optimize
away the cost of set-up for short-lived sessions?
===

Whether that should be a section of its own, or a couple of questions merged
e.g., in 2.7 is your call.

3.4  How is the binding updated?

     Will transport connections remain up when new paths become available
     or when old ones become unavailable?  How does the end node discover
     these events?

==> You should probably also ask:

     How long does it take to notice new paths?  How long does it take to
     notice paths which are already used which have become unavailable?

...

3.12  Are there any implications for scoped addressing?

     Please see RFC 3513 [1].  How does your mechanism interact with
     multicast?

==> what does 'multicast' have to do under 'scoped addressing'.  Granted,
multicast addresses have a concept of scope, but maybe this calls for an
additional question, 'Are there any implications for multicast', where
multicast would include both global and non-globally scoped mcast.

4.3  Are there any changes to ICMP error semantics?

     Do you create new codes?  If so, why and what do they mean? Will a
     host that is not aware of your scheme see them?

==> add 'What would happen if such ICMP messages would end up being filtered
e.g. in a firewall?'..

5.  Name service interactions

==> you discuss DNS in this section, but AFAICS, these issues could be
generic if some other mapping function than DNS would be used.  Maybe this
issue could be handled by adding something like:

   This section assumes that DNS might be used for a mapping function.  If
   you are using some other method (see Section 3.8), please consider
   separately both the impact on DNS, and the impact on your mapping function
   as appropriate.

editorial
---------

     This document contains several set of questions that attempt to focus

==> plural/singular

     It is the hope of the author perhaps others that the authors of the
     proposed solutions will use this document to identify gaps in their
     solutions, and cooperate to close those gaps.

==> something missing here

     If so, how are rendezvous handled?  Can your solution handle both

==> plural/singular

     it?  If not, how will your solution interact with MOBILEIP-V6 [3]

==> that's an interesting way to write it:) try 'Mobile IPv6'

     While Ipv6 has a simplified approach to layer 2, perhaps you
     unsimplified it.  If so, please provide details.

==> s/layer 2/the link layer/

     How does your solution interact with link-local addressing

==> add '?' at the end?

     How does your solution interact with Son-Of-Sitelocal (whatever that
     will be)?

==> just reference ULAs ?

     If a link fails or a service is dropped, how will it impact DNS?
     Again are there any dependency loops?  Perhaps diagram out your
     dependencies to make sure.

==> is 'diagram out' a verb?

     Referrals exist within various other protocols, such as so-called
     "peer to peer" applications.  Note that referrals might suffer three
     types of failure:
        firewall and NAT - just as FTP active mode experiences today with
        relatively simple firewalls?
        time-based - is there something ephemeral about the nature of the
        solution that might cause a referral (such as a URL) to fail over
        time, more so than what we have today?
        location-based - if the binding varies based on where the parties
        are in the network, if one moves will they no longer be able to
        find one another?

==> some numbers, bullets, etc. for these 3 would be nice

     [3]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
          IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
          2003.

==> rfc 3775 now

     [4]  Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
          solutions", draft-nordmark-multi6-threats-00 (work in progress),
          October 2003.

==> draft-ietf-multi6-multihoming-threats now

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 28 Oct 2004 13:41:05 +0200

Pekka,

> OK, but I don't think there is a good document laying these out.

I agree with you to some extent, but I read the question being 
"describe the problems you are trying to solve". Which I think is 
closer to your point.

> e.g., in 2.7 is your call.

I think that might actually be worth a question on it's own.

- - kurtis -

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Oct 2004 14:09:09 +0200

Hi Pekka,

> 2.3.3 Can your solution be aggregated and implemented site-wide?

This is now in Section 4.1: does your solution change existing 
aggregation methods?

> MPLS, when it should be focusing on BGP traffic engineering practices

We had this in there and nobody could understand how a solution could 
impact traffic engineering methods, other than by changing the 
aggregation methods.  Thus Section 4.1.

> proposal solve the spam problem?'.  This question is not good, because I 
> don't think we have sufficiently clearly defined what "the multihoming 
> problem" really is (and some might even argue it's multiple different 
> problems), and its unlikely that the solutions can even solve the whole 
> problem.
> 

What I am looking for, and perhaps a clarification *is* in order, is a 
scoping of what problem they think they're trying to solve.  This 
document doesn't require you to solve every problem, but simply to 
explain how your solution to the problem you think you're solving will 
impact the world we live in now.

> "multihoming set-up") to happen after the session has been

This is included above based on your earlier feedback.

> away the cost of set-up for short-lived sessions?

And this may be too specific to a mechanism you have in mind.  For 
instance, perhaps this would be handled by an IP end host option.

>     notice paths which are already used which have become unavailable?

That's a good question.
> multicast would include both global and non-globally scoped mcast.

The question is right there.  I attempted to borrow from IPv6 
nomenclature.  If you believe that nomenclature is failing us here, then 
we should change it, but we should do so elsewhere as well.

> ==> add 'What would happen if such ICMP messages would end up being 

Ok.

>   separately both the impact on DNS, and the impact on your mapping 

I don't want to make quite so broad an assumption about the solution 
space, since we don't quite know which problem people are working on.

> editorial

Will modify as appropriate.

Eliot

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Oct 2004 17:02:13 +0100

Hi,

Could/should we add a note that IPv6 renumbering (without a flag day) will
generally involve a site being multihomed in a transient phase between
using one prefix and adopting a new prefix?

[I recall for Fred's "IPv6 renumbering procedure" draft we discussed the
 relevance of multihoming to renumbering, and I think the reverse applies.]

A difference is the (probably) each node will be configured to prefer one
uplink over the other as an existing prefix is deprecated and a new prefix
introduced, as described in Fred's document (in contrast to being able to
use both links, with neither being deprecated).

We added some notes on the linkage to section 5.9 of
http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-00.txt
which can probably be improved.

A site could also change provider for one of its two uplinks if dual-homed, 
in which case a site may be triple homed while it's primary or secondary 
existing uplink provider changes and is renumbered.

Tim

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Oct 2004 18:10:38 +0200

Hi Tim,

> using one prefix and adopting a new prefix?

I think i am missing your point...

why does a multi6 solution designer consider this when designing a  
solution?

I mean, as some folks have mentioned earlier, it is good to keep this  
doc short,

Regards, marcelo

> existing uplink provider changes and is renumbered.
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Oct 2004 19:02:14 +0200

> using one prefix and adopting a new prefix?

Yes, this makes sense.  Could you suggest text?

Thanks,

Eliot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Oct 2004 20:39:00 +0300 (EEST)

On Thu, 28 Oct 2004, Eliot Lear wrote:
> This is now in Section 4.1: does your solution change existing aggregation 
> methods?

Oh yes, sorry -- I missed that.

> We had this in there and nobody could understand how a solution could impact 
> traffic engineering methods, other than by changing the aggregation methods. 
> Thus Section 4.1.

Yes, the text was probably focused wrong.

Maybe it should have been something like:

X.Y Does the solution solve traffic engineering requirements?

One of the significant goals of IPv4 multihoming solutions has been to 
be able to perform traffic engineering based on appropriately 
adjusting the BGP advertisements. If the prefixes used by the sites 
would be aggregatable, the sites' ability to perform traffic 
engineering would be diminished.

Does the solution offer ways for site the to manage its traffic flows? 
If so, how?  Is this controllable on a per-host basis, or on a 
per-site basis?

.... i.e., there should be some section which forces the solution 
developer to think, "gee, if the site would no longer be allowed to 
advertise more specific prefixes, or any prefixes that would get into 
the global routing table, how would it fill its traffic engineering 
needs?  Or is this left unsolved? [which seems to be the case now]"

> scoping of what problem they think they're trying to solve.  This document 
> doesn't require you to solve every problem, but simply to explain how your 
> solution to the problem you think you're solving will impact the world we 
> live in now.

I agree with that.  The text needs some tuning to make it loud and 
clear that there is not a single big problem to be solved, and the 
responder should articulate which problems he's trying to solve.

> This is included above based on your earlier feedback.

Piggybacking can mean multiple things.  This is not sufficient, see 
below.

> And this may be too specific to a mechanism you have in mind.  For instance, 
> perhaps this would be handled by an IP end host option.

You seem to make the assumption that as long as no additional messages 
would be sent, it would be OK.  That's not the case: my proposed text 
was also addressing the situation where you wanted to avoid the extra 
*overhead* and processing at the start of the sessions.  The 
piggybacking text could be read to just refer to being able to bundle 
the messaging right from the start, right?

Trying to say it differently, so that it'll be clear for certain:
  - piggybacking has protocol overhead, which can be undesirable for 
many reasons (and it might not even be possible to completely 
piggyback the packets), requiring e.g., new options, and such packets 
might be dropped in the firewalls

  - if you do piggybacking from the start, you'll waste bytes and 
processing even for short, 1-2 second flows.  That seems like 
something that one might want to do away with.

Delaying the multihoming set-up from the initial signalling would do 
just that, whether it would be piggybacked ont he data packets, or 
sent separately.

Again, it's not clear whether this is a tradeoff to pick, but it 
should be on the list of things to think about :-)

> The question is right there.  I attempted to borrow from IPv6 nomenclature. 
> If you believe that nomenclature is failing us here, then we should change 
> it, but we should do so elsewhere as well.

I'm not sure if I understand your comment.  The grouping of the 
questions seems to be odd, because handling (global) multicast has 
probably different things to think about, than handling link-local or 
ULA unicast.  The latter has to do with scoping, the former.. well, 
there are always some problems with multicast which one might not have 
thought of :-)

> I don't want to make quite so broad an assumption about the solution space, 
> since we don't quite know which problem people are working on.

That's cool.  But there are a lot of questions about DNS which should 
be asked in closely identical fashion if someone invents his or her 
own discovery service.  What would the best place to require them to 
discuss those issues?  Seems to have significant overlap here..

A possible approach might be generalizing some of the generic DNS 
questions, and keeping some of them which are related to the continued 
well-being of DNS (which might not be a problem if the solution 
invents its own for its own stuff).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Oct 2004 21:05:10 +0200

Hi Pekka, Elliot,

> If so, how?  Is this controllable on a per-host basis, or on a 

Yes, imho this is relevant.
Perhaps we could also consider the differences between incoming and 
outgoing traffic...

Regards, marcelo

>>> ==> this seems almost like asking, in an email context, 'how does 
>>> your proposal solve the spam problem?'.  This question is not good, 
>>> because I don't think we have sufficiently clearly defined what "the 
>>> multiple different problems), and its unlikely that the solutions 
>>> can even solve the whole problem.
>> What I am looking for, and perhaps a clarification *is* in order, is 
>> a scoping of what problem they think they're trying to solve.  This 
>> explain how your solution to the problem you think you're solving 
>> will impact the world we live in now.
>
>> nomenclature. If you believe that nomenclature is failing us here, 
>> then we should change it, but we should do so elsewhere as well.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2004 10:50:41 +0200

> Yes, this makes sense.  Could you suggest text?

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?

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 29 Oct 2004 10:30:58 +0100

> 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