[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-multi6-multihoming-requirements-00
- To: firstname.lastname@example.org
- Subject: Comments on draft-ietf-multi6-multihoming-requirements-00
- From: Brian E Carpenter <email@example.com>
- Date: Wed, 04 Apr 2001 16:51:29 -0500
- Delivery-date: Wed, 04 Apr 2001 14:54:29 -0700
- Envelope-to: firstname.lastname@example.org
- Organization: IBM
(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 , 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 , which assumes that routing table entries
can be aggregated based upon a hierarchy of customers and
> However, it appears that this hierarchy is being supplanted by a
> dense mesh of interconnections . 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
Shouldn't this be:
aggregate, are announced by the customers' alternative service providers,
separately from the announcement of the larger aggregate by the
> ...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
> 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:
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.
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.