[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSE vs. Multiple Addresses: pros & cons
On Wed, Jun 20, 2001 at 01:42:24PM -0500, Brian E Carpenter wrote:
> Since we don't have an agreed requirements list, I don't see
> how we could have a pros and cons list yet.
Updating the requirements draft has been on my plate for a while;
apologies for being so slack on this.
I have the following notes for modifications to the current draft
that I will attempt to make in the next few days. Please shout if
there's something missing from this list that should be there.
These are more-or-less in the order that mutt threaded them in
(i.e. fairly arbitrary, but to some extent chronological).
I also jotted down some references that I noticed on the way, and
put them at the end.
Joe
GENERAL
+ replaces references to "autonomous systems" where use of BGP is
not intended to be implied. RFC1918 defines an "enterprise".
+ mention the case of multiply attaching to the same provider
+ "connected to the Internet" might be better phrased as "part of
the Internet"
+ security considerations
+ "load sharing" might be a better phrase than "load balancing" in
some/most contexts
+ references to other work discussing scaling and convergence
problems with the current v4 multi-homing architecture
+ "re-routing" needs to be used much more carefully, since we
should not assume the best solution lies at the routing layer.
It may pay to define a specific term to describe the network
event which requires changes in traffic behaviours currently
achieved by "re-routing" through a BGP withdrawal or announcement,
like "re-homing event" or something
+ clarify that path selection based on (e.g.) TCP port numbers
is not in scope (as suggested possibly in section 3.4 of the
current draft)
+ specify that the multihoming solution *allows* host and app
changes to enhance session survivability
+ make clear the distinction between the ability to establish a
new transport-layer session and the ability to maintain existing
transport-layer sessions following a re-homing event
+ Second sentence of the introduction might be re-written;
Brian's suggestion is
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.
+ "inter-provider routing system" may be a good alternative to
the phrase "routing protocols and routing hardware"
+ "Migration to IPv6.... exacerbate..." sentence in the introduction
might be wr-written. Brian's suggestion is
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.
+ make it clearer that load sharing is for resource balancing in
the interests of performance; think about whether load sharing
has specific requirements not covered elsewhere
+ section 3.4 might be re-written under the heading "Policy" instead
of "Cost". Brian's suggestion is:
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.
+ we might be more precise about what we mean by scalability of
the multi-homing requirement.
+ specify that the multihoming solution *allows* host and app
changes to enhance session survivability, rather than *requiring* it
+ Brian suggests additional sections:
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.
+ think about whether the "overview of the current architecture"
really belongs in this document, or whether it might be happier
living some place else
+ "The solution may involve interaction between a site's hosts and its
routing system; this interaction should be simple, scalable, and
secureable." (Bill Sommerfeld)
+ Make it more clear as what the requirements actually *are*. It has
been mentioned that the document assumes some context which should
be spelt out. Make the draft look more like a requirements document,
in fact.
+ The multihoming solution needs to include a mechanism for shifting
specific traffic between prociders when more than one is available
(Margaret).
+ Heuristics for a good design: simplicity, minimal impact on existing
host implementations, ability to converge on new information quickly
(Margaret).
+ Compatability requirements. Margaret suggested:
Existing IPv6 host implementations, including
- IPv6 host autoconfiguration
- IPv6 over PPP?
- DHCPv6 configuration?
IPv6 Transition Mechanisms
- Bump-in-the-Stack
- Bump-in-the-API
- NAT-PT
- Tunneling mechanisms?
- Others?
Existing host-based transport layers:
- TCP, UDP, etc.
- SCTP?
- Others?
Existing IPv6 Routing Protocols?
REFERENCES
draft-nikander-mobileip-homelessv6-01.txt
On Wed, 4 Apr 2001 10:10:00 -0700, Steve Deering <deering@cisco.com> wrote:
> If this group is to pursue host-based or transport-layer multihoming,
> you might want to look at some of the material presented at the Tokyo
> interim meeting of the IPng working group in Sept/Oct 1999, fetchable
> from <http://playground.sun.com/ipng/meetings.html>. For example,
> my "Overview of IP(v6) Multihoming Issues" is one attempt to
> characterize the problem space and list a range of (increasingly
> ambitious) goals one could set for host-based multihoming, and the
> presentation from Peter Tattam entitled "Preserving Active TCP
> Sessions" was one stab at enhancing TCP for multihoming.
On Wed, 4 Apr 2001 20:02:01 +0200, Feico Dillema <feico@PASTA.cs.uit.no> wrote:
> As a side-note; Peter Tattam's proposal has been implemented by one of
> our students in 1999 for the Kame stack on *BSD. If there's an
> interest in the code (and maybe thesis too) to look at or maybe to
> revive (on a more -current Kame stack) for actual experimentation, I
> can put it online (and maybe revive it myself) once I'm back from a
> (well-deserved! ;) vacation, i.e. in one or two weeks from now. Just
> leave me a note, if you're interested...
draft-ietf-sigtran-sctp-applicability-05.txt
draft-stewart-sctpsocket-sigtran-02.txt
draft-ohta-e2e-multihoming-01.txt