Subject: GSE vs. Multiple Addresses: pros & cons

From: "Joseph T. Klein" <[email-masked]>
Date: Wed, 20 Jun 2001 17:49:27 +0000

Has anyone attempted to build working code for the GSE proposal?
Any consensus on the pros and cons of these two proposals?
-- 
Joseph T. Klein                                         +1 414 915 7489
Senior Network Engineer                                 [email-masked]
Adelphia Business Solutions                [email-masked]

     "... the true value of the Internet is its connectedness ..."
                                                  -- John W. Stewart III

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2001 13:42:24 -0500

Since we don't have an agreed requirements list, I don't see
how we could have a pros and cons list yet.

   Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Jun 2001 16:28:34 -0400

> 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 <[email-masked]> 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 <[email-masked]> 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