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

On Thu, 21 Oct 2004, Brian E Carpenter wrote:
> 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 protected]
> 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