comments on draft-ietf-multi6-v4-multihoming-00.txt

[Pekka Savola <pekkas@netcore.fi>]

substantial
-----------

3. Motivations for Multihoming

==> this section should be removed completely, as it is duplicated
in the multihoming goals document now.

4. Features of IPv4 Multihoming

==> this document assumes a prior knowledge of what "*THE* IPv4
multihoming solution" is.  This has not been described anywhere.
So, I'd propose to add a new section to replace sect 3 to describe
a few common ways of doing it.  There should be enough meat here, as
I had 16 pages of analysis of current methods in my thesis about
site multihoming.

basically, I think you can divide the IPv4 multihoming techniques
to about five different types:

 1) multihoming using your own AS number and your own prefix,
    advertising them through multiple providers.

 2) multihoming using your own AS number, but advertising 
    a more specific prefix from one of your ISPs.  Some of these
    are multihomers (the backup is through the ISP which announces
    the aggregate), some have just bought the prefix when they
    changed ISP.

 3) multihoming with your own prefix, but without your own (public)
    AS number.  As the cost of the AS is low, this is rather rare.
    The customer uses private AS numbers or the ISP proxy-advertises
    the prefixes.  Nondistinguishable from "origin theft" as multiple
    AS's seem to be originating the same prefix.

 4) multi-attaching multiple times to an ISP, even though not
    strictly multihoming, is also popular.  This is a very simple
    operation, and often the tradeoffs (unless you want independence
    as a multihoming motivation) are acceptable if you pick the right
    provider.

 5) employing NAT-based or RFC2260 -like solutions (you could also
    separate these two) to achieve at least some multihoming
    benefits.  Typically you cannot get everything, but for some,
    this has been enough.

In section 4, you've analyzed only 1).  This may be OK, as the
characteristics are similar with the other major method, 2).  But
this needs to be spelled out.  Another way would be analyzing each
of these in turn, or the like.

==> you should also include the analysis of the "additional features"
of the multihoming goals document wrt IPv4 multihoming, I guess?

==> the lists are also not up-to-date, as you don't list e.g. DNS or 
packet filtering.

6. Security Considerations

   Security considerations are not discussed in this draft.

==> this must be a flame-bait :), so replace it with something like:

   This memo analyzes the IPv4 multihoming practices.  This analysis
   only includes the description of the mechanisms and partially how
   they affect the availability of the site deploying the IPv4
   multihoming mechanism.  Other security properties of the IPv4
   multihoming mechanisms are not analyzed.

5. Limitations of IPv4 Multihoming

5.1 Scalability

==> I'd also add here something like:

   These mechanisms also add to the consumption of public AS number
   resources, when small sites wishing to multihome obtain an AS
   number specifically for only that purpose.  Using a different
   mechanism would help to conserve the 16-bit AS number space, and
   avoid the move to 32-bit AS numbers.

editorial
---------

==> throughout the document, one uses "enterprises" rather than "sites"
-- is this intentional?

Abstract

   Multihoming is an essential component of service for enterprises [3]
   which are part of the Internet.  This draft describes some of the
   motivations, practices and limitations of multihoming as it is
   achieved in the IPv4 world today.

   The context for this discussion is the requirements analysis for site
   multihoming in IPv6, which is described in a companion draft [1]. 

==> the abstract must not include references

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

==> these terms can be removed, they shouldn't be used in a document
like this anyway.

References

==> references need to split to informative and normative.

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