Comments on draft-ietf-multi6-multihoming-requirements-00

[Brian E Carpenter <brian@hursley.ibm.com>]

Hi,

> Abstract
(would require reworking if you accept some of my other comments)

...
> 
> 1. Introduction
> 
>    Multihoming is an essential component of service for autonomous
>    systems connected to the Internet.  The existing multihoming
>    architecture is based on CIDR [1], which is predicated upon a
>    hierarchy of service providers.

I think it's going too far to refer to a multihoming "architecture".
And it isn't actually based on CIDR; it's more like CIDR abuse. So I
would rewrite the second sentence:

    Current multihoming practice has been added on to the CIDR
    architecture [1], which assumes that routing table entries
    can be aggregated based upon a hierarchy of customers and
    service providers. 

> 
>    However, it appears that this hierarchy is being supplanted by a
>    dense mesh of interconnections [5].  Additionally, there has been an
>    enormous growth in the number of multihomed organizations. For
>    purposes of redundancy and load sharing, the multihomed customer
>    blocks, which are almost always a longer prefix from the provider
>    aggregate, are announced, along with the larger aggregate by the
>    provider. 

Shouldn't this be:

   aggregate, are announced by the customers' alternative service providers,
   separately from the announcement of the larger aggregate by the
   original provider.  
    
>    ...This results in rapidly increasing size of the global
>    routing table. This explosion places significant stress on both the
>    routing protocols and the routing hardware.

I'd just say "on the inter-provider routing system."
> 
>    Migration to IPv6 with its greatly enlarged address space is likely
>    to exacerbate the weaknesses in the existing system.

    Migration to IPv6, which will allow unprecedented scaling of the
    number of potentially multihomed sites, will seriously exacerbate 
    this stress unless a substantially different approach to multihoming 
    is adopted.
> 
...
> 
> 3. Multihoming Requirements
...
> 3.2 Load Sharing
> 
>    Load sharing is distributing traffic across multiple links. Reasons
>    for load sharing include but are not limited to: 
> 
>    o  Performance,
> 
>    o  Cost, and
> 
>    o  Availability of Infrastructure.

[but these are the same points as in the next 3 sections - I think you need
to rethink this. Shouldn't we be more explicit that load sharing is
for resource balancing in the interests of performamce? Alternatively, does
load balancing actually have any specific requirements not covered elsewhere?]

...
> 
> 3.4 Cost
> 
>    A provider may choose to multihome for financial reasons.  For
>    example, customer C homed to ISP A may wish to shift traffic of a
>    certain class or application, NNTP, for example, to ISP B because
>    ISP B charges less for traffic.  Any future multihoming proposals
>    must provide support for multihoming for financial reasons.

I don't like this in an IETF document. I think it should be abstracted
out as a policy matter. Suggested rewrite:

 3.4 Policy

   A customer may choose to multihome for a variety of policy reasons
   outside technical scope (e.g. cost, acceptable use conditions, etc.)
   For example, customer C homed to ISP A may wish to shift traffic of a
   certain class or application, NNTP, for example, to ISP B as matter
   of policy.  Any future multihoming proposals must provide support 
   for multihoming for external policy reasons.

...
> 3.6 Simplicity and Scalability
> 
>    As any proposed multihoming solution must be deployed in real
>    networks with real customers, simplicity is paramount. The current
>    multihoming solution, despite its drawbacks, is quite
>    straightforward to deploy and maintain.
> 
>    Unlike the current solution, however, new solutions must provide for
>    scaling of the number of multihomed sites many orders of magnitude
>    larger than are currently deployed. The limitations for scalability
>    with the existing solution and current protocols are outlined in
>    Section 4.

I think we have to be more precise here. Assuming we currently have the
BGP table growing like k+N (where N is the number of multihomed sites),
do we aim at it growing like k+log(N), or what?

Now here's what's missing:

3.7 Impact on routers

  The solution may require changes to IPv6 router implementations, but these 
  changes must be either minor, or in the form of logically separate functions
  added to existing functions.

  Such changes must not prevent normal single-homed operation, and routers
  implementing these changes must be able to interoperate fully with hosts
  and routers not implementing them.

3.8 Impact on host stacks

  The solution must not destroy IPv6 connectivity for a legacy host 
  implementing RFC 2373, RFC 2460, RFC 2553 and other basic IPv6 
  specifications current in 4/2001. That is to say, if a host can work 
  in a single-homed site, it must still be able to work in a 
  multihomed site, even if it cannot benefit from multihoming.

  It would be compatible with this requirement for such a host to lose 
  connectivity if the site's primary ISP connection failed.

  If the solution requires changes to the host stack, these changes
  must be either minor, or in the form of logically separate functions
  added to existing functions.

  If the solution requires changes to the socket API and/or the transport
  layer, it must be possible to retain the original socket API and transport
  protocols in parallel, even if they cannot benefit from multihoming.

3.9 Operations and management
 
  It must be possible to monitor and configure the multihoming system.

3.10 Security

  Multihoming no doubt offers some attractive opportunites for denial
  of service and spoofing attacks. Multihomed sites must be protected against
  such attacks at least as well as single-homed sites.



> 4. Overview of the Current Architecture

I'm not sure this section belongs in this document. I think a
considerably longer stand-alone document would be better,
to document the trouble in much more detail. Or maybe persuade
Geoff to add this topic to his BGP document.

Regards

    Brian