comments on requirements draft

[Steve Deering <deering@cisco.com>]

Here are some comments on the -01 version of the multi6 requirements
draft.

>             Requirements for IP Multihoming Architectures

Shouldn't this say "Site Multihoming" or "Enterprise Multihoming" or
something like that, to distinguish it from the other common uses of
the term "multihoming", such as host multihoming (i.e., having more
than one address or more than one interface on a host)?

>Abstract
>
>   Multihoming is an essential component of service for enterprises [3]
>   which are part of the Internet.  Existing IPv4 multi-homing...

"Multihoming" is used before it is defined.  How about something like
the following:

    Multihoming, that is, connecting to more than one IP service
    provider, is an essential component for enterprises...


>   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.

It's not the move to IPv6 that will exacerbate the stress -- it's
the growth of the Internet and of multihoming, regardless of which
version of IP will be used.  It is often claimed that IPv6's larger
address will make the problem worse, as if the shorter length
of IPv4 addresses were acting as some sort of defense, which is
just not true.  The 32-bit space already accommodates "unprecedented
scaling of the number of potentially multihomed sites" way beyond
what can be handled with the current multihoming approach, as we
we move more and more towards giving sites only one or a small
number of public IPv4 addresses and expecting them to use NAT.
I.e., the current direction is intractable; IPv6 doesn't make it
"more intractable".

>   An "enterprise" is an entity autonomously operating a network using
>   TCP/IP and, in particular, determining the addressing plan and
>   address assignments within that network.  This is the definition of
>   "enterprise" used in [3].

I wonder why "TCP/IP" and not just "IP"?  Must an enterprise use TCP?

>3.1.1 Redundancy
>
>   By multihoming, an enterprise should be able to insulate itself from
>   certain failure modes within one or more transit providers, as well
>   as failures in the network providing interconnecting with one or more
>   transit providers.

"providing interconnecting with" is awkward.  How about "providing
interconnection among"?

>   The multihoming architecture must accommodate (in the general case,
>   issues of shared-fate notwithstanding) the following failure modes:

s/accommodate/survive/

>   o  Physical link failure, such as a fiber cut or router failure,

A router failure is not an example of a physical link failure.


>3.1.2 Load Sharing
>
>   By multihoming, an enterprise should be able to distribute both
>   inbound and outbound traffic between multiple transit providers.

s/between/across/

Also, change or add wording to make it clear that the requirement is
for potentially *concurrent* usage of the multiple connections, not
just the usage of one provider over one interval of time and another
provider over a different interval.

>3.1.3 Performance
>
>   By multihoming, an enterprise should be able to protect itself from
>   performance difficulties between transit providers.
>
>   For example, suppose enterprise E obtains transit from transit
>   providers T1 and T2, and there is long-term congestion between T1 and
>   T2.  The multihoming architecture should allow E to ensure that in
>   normal operation none of its traffic is carried over the congested
>   interconnection T1-T2.

How is the capability offered in the current multihoming approach,
given that BGP is not sensitive to congestion, short-term or long-term?

>   A multi-homed enterprise must also be able to distribute inbound
>   traffic particular multiple transit providers according to the
           ^
           from

>   particular network within their enterprise which is sourcing or
>   sinking the traffic.

How can a network within the enterprise source inbound traffic to that
enterprise via a particular transit provider?

This Performance section needs more elaboration and clarification.


>3.1.4 Policy
>
>   A customer may choose to multihome for a variety of policy reasons
>   outside technical scope (e.g.  cost, acceptable use conditions, etc.)
           ^
           the?

>   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.  A new IPv6 multihoming proposal must provide support for
>   multihoming for external policy reasons.

Inbound only?  Outbound only?  Both?  This requirement seems excessive
to me, e.g., if end systems ESP encrypt their traffic, how can the
network recognize NNTP traffic?

>3.1.5 Simplicity
>
>   As any proposed multihoming solution must be deployed in real
>   networks with real customers, simplicity is paramount.  The current
>   multihoming solution is quite straightforward to deploy and maintain.
>   A new IPv6 multihoming proposal must not be substantially more
>   complex to deploy and operate than current IPv4 multihoming
>   practices.

Complexity is in the eye of the beholder.  Also, the acceptability of
complexity may well depend upon whom the complexity is being imposed,
and on what benefits one gets in return for that complexity.  BGP and
OSPF are more complex than RIP, but their advantages are apparently
deemed worth their extra complexity.  So while simplicity is a very
important goal, and we each believe we know complexity when we see it
(even when others disagree), it's not feasible in this context to
measure complexity or agree on how much is too much, so it cannot
reasonably be made a "requirement".


>3.2.1 Scalability
>
>   Current IPV4 multihoming practices contribute to the significant
>   growth currently observed in the state held in the global inter-
                                               ^
                                   and information exchanged?

>   provider routing system; this is a concern both because of the
>   hardware requirements it imposes and also because of the impact on
>   the stability of the routing system.  This issue is discussed in
>   great detail in [9].
>
>   A new IPv6 multihoming architecture should scale to accommodate
>   orders of magnitude more multi-homed enterprises without imposing
>   unreasonable requirements on the routing system.

How many orders of magnitude?

>3.2.2 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.

This is a surprising requirement -- can you elaborate?   Also, the
nature and degree of acceptable change would presumably depend on
whether or not the change was required in the data plane (already being
cast in hardware for IPv6 on some routers) or the control plane
(still in software), and perhaps also on how many routers would have
to change, e.g., all routers vs. backbone routers vs. edge routers vs.
enterprise routers.

>3.2.3 Impact on Hosts
>
>   The solution must not destroy IPv6 connectivity for a legacy host
>   implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic
>   IPv6 specifications current in June 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.

Is the assumption that there's a "primary" ISP always valid?

What about newly-established sessions?

>   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.

This needs more elaboration.

>   The multi-homing solution should allow host or application changes to
>   enhance session survivability.

s/to enhance/if that would enhance/

>3.2.5 Operations and Management
>
>   It must be posssible to monitor and configure the multihoming system.

Possible for whom?

>4. Security Considerations
>
>   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.

I.e., not at all?


- Steve