Re: Differentiating multihoming in IPv6 requirements

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

Actually, if you look at the text, multi6 is *not* doing a requirements
document any more. The draft is a list of goals which are all qualified
by "should". I think we understand that satisfying all of the goals
simultaneously is impossible.

   Brian

Iljitsch van Beijnum wrote:
> 
> Over the course of a private discussion we (Harold Grovesteen and
> Iljitsch van Beijnum) have come to the conclusion the way both multi6
> and ipv6mh handle the "requirements problem" is unsatisfactory. Multi6
> is still set on delivering a requirements document, but it is generally
> recognized that it is impossible for a single solution to meet all the
> requirements in the current document. Ipv6mh on the other hand, rejects
> any requirements in order to avoid getting stuck. This means multi6
> fails to develop any solutions, while ipv6mh develops too many, and
> quite possibly ones that fail to meet user expectations. (Anyone who
> has ever owned a V2000 or Betamax VCR knows that too many solutions for
> a single problem isn't good.)
> 
> We believe we can find middle ground here by not pursuing single
> solutions that meet all requirements, but recognizing that there are
> three classes of solutions that each require different requirements:
> short, intermediate and long term solutions. This way, we can have both
> a solution that can be deployed in the near future, and a solution that
> provides near-unlimited scalability and a clean architecture, rather
> than something that takes too long to develop and still doesn't provide
> everything we want.
> 
> The most important requirement for short term solutions is that they
> can indeed be deployed in the short term. That means either doing
> something in routing using current protocols, or doing something in
> hosts that works if only one side of the connection is a modified host.
> Short term solutions don't have to scale to more than a few million
> multihomers (although it wouldn't hurt if they could), as long as any
> "pollution" (of the global routing table, for instance) can be cleaned
> up at some point. There can be several short term solutions.
> 
> The requirements for long term solutions are very different. Here
> scalability is key. This, and the end-to-end principe suggest that long
> term solutions be implemented in individual hosts. Long term solutions
> also need a clean architecture, preferably one where we know we can
> support future developments at  the transport and lower layers without
> another round of changes to applications. For long term solutions, it
> isn't much of a problem that both ends of a connection must be modified
> for it to work. (Although a smoother upgrade path than just sit out the
> whole chicken/egg thing would be good.) More than a single long term
> solution would be undesirable.
> 
> Intermediate solutions should bridge the gap. For an intermediate
> solution, it's still not acceptable to have to change all hosts, but
> changing all sites or all ISPs (by putting in proxy multihoming
> processing boxes) should be acceptable. Intermediate solutions should
> be very scalable and have a decent (but presumably  not perfect)
> architecture because the life time of intermediate term solutions could
> be longer than expected as it might be a very long time before a long
> term solution is widely implemented. An important feature for
> intermediate solutions is that they work well with both short term
> solutions and with long term solutions. This probably means explicit
> support for all short term solutions in all intermediate
> implementations, and some kind of meta-solution that makes it possible
> for intermediate and long term solutions to work together.
> 
> Some comments on the requirements document in this light:
> 
>       By multihoming, a site must be able to distribute both inbound and
>       outbound traffic between multiple transit providers.  This
>       requirement is for concurrent use of the multiple transit
> providers,
>       not just the usage of one provider over one interval of time and
>       another provider over a different interval.
> 
> Short: since we can do this for inbound with multiple A records and for
> outbound with some (static) routes, at solution doesn't really have to
> support this
> Intermediate: highly desired / required
> Long: required, preferably even load balance a single session over
> multiple paths
> 
>       By multihoming, a site must be able to protect itself from
>       performance difficulties directly between the site's transit
>       providers.
> 
> This is a good example of something we could easily drop for short term
> solutions.
> 
>       Multihoming solutions must provide re-homing transparency for
>       transport-layer sessions; i.e.  exchange of data between devices on
>       the multihomed site and devices elsewhere on the Internet may
> proceed
>       with no greater interruption than that associated with the
> transient
>       packet loss during the re-homing event.
> 
> Again, something that would definitely be a requirement for
> intermediate or long term solutions, but if we can have the ability to
> set up new sessions for a short term solution, that's better than
> nothing.
> 
>       A new IPv6 multihoming architecture must scale to accommodate
> orders
>       of magnitude more multihomed sites without imposing unreasonable
>       requirements on the routing system.
> 
> Short: has to be much better than simple PI, but a billion or more
> isn't necessary
> Intermediate: required, as there may not be a long term solution after
> all
> Long: required
> 
>       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.
> 
> Short: required
> Intermediate: required
> Long: desired: forklift upgrades are bad, but if we then get the
> perfect solution it may be worth it and/or we can wait out the natural
> economic life span of existing equipment
> 
>       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 November 2002.  That is to say, if a
>       host can work in a single-homed site, it must still be able to work
>       multihoming.
> 
> Short: required
> Intermediate: required
> Long: interoperability should remain but we can expect people to
> upgrade at some point, so just "desired"
> 
>       A multihoming strategy may require cooperation between a site and
> its
>       transit providers, but must not require cooperation (relating
>       specifically to the multihomed site) directly between the transit
>       providers.
> 
> Short: required (not all ISPs will upgrade immediately)
> Intermediate: highly desired (if this is the only downside, we can live
> with it, for a while anyway)
> Long: required
> 
> Harold Grovesteen
> Iljitsch van Beijnum