General Feedback on Requirements

[Margaret Wasserman <mrw@windriver.com>]

I sent feedback on the requirements very early on, and I 
guess that I was not specific enough about the changes 
that I feel are required, since the authors did not think
that changes were warranted.  So, let me be more specific.

Please note that I am not trying to insult anyone's 
efforts.  I know that it is a difficult task to put up
the first strawman for a set of requirements, and I 
appreciate the efforts of the authors.  However, I am not
satisfied with the current document and do not support moving
forward with it in its current form (or with minor 
changes) as a working group product.

Although the document gives a nice definition of multihoming
and provides a good explanation of the reasons why someone
might want to multihome a site, it is not very explicit
in stating the requirements for an IPv6 multihoming solution.
In fact, it does not list many actual requirements.

When the document does list requirements, it is not rigorous
enough.  It doesn't define its terms or make it clear what
is required.  

I don't think that we could reasonably use this document as
a litmus test for IPv6 site multihoming proposals.

As far as I can tell, the only section in the draft which
list requirements is section 3.  This section is about
two pages long, so I will reproduce it here with my comments:

>Multihoming Requirements
>
>    Multihoming is the connection of one autonomous system to multiple,
>    other autonomous systems.  This is done for reasons of service
>    redundancy and reliability, and also for load-sharing.

This paragraph contains no requirements.


>3.1 Redundancy
>
>    By obtaining transit through more than one provider, a network can
>    insulate itself from certain failure modes of one or more providers,
>    as well as failures within layer 1 and layer 2 infrastructure.
>
>    Specific failure modes which must be protected against by any
>    solution for site multihoming in IP networks include: 
>
>    o  Physical link failure, such as a fiber cut or router failure,
>
>    o  Logical link failure, such as a misbehaving router interface,
>
>    o  Routing protocol failure, such as a BGP peer reset,
>
>    o  Service provider failure, such as a backbone-wide IGP failure, and
>
>    o  Exchange failure, such as a BGP reset on an inter-provider
>       peering.

Although this would seem to be a set of requirements, it doesn't
really say anything unless you define the terms "insulate", 
"protected" and "failure".

_Exactly what functionality_ needs to work when these failure events
occur?  

I attempted to write some text that distinguished between different
types of "protection" (i.e. maintaining existing connections vs.
the ability to establish new connections), and I would like to see
that sort of wording added to the requirements document.

>    Additionally, during failure events described above, multihoming
>    solutions must provide re-routing transparency for applications;
>    i.e. exchange of data between devices on the multi-homed network and
>    devices elsewhere on the Internet may proceed with no greater
>    interruption than transient packet loss during the re-routing event.

As mentioned before, this paragraph implies a routing solution.

That aside, I think that it is trying to say that TCP sessions must
be able to survive a failure?  I'm not sure, though.  The definition
of this requirement is not rigorous enough to determine whether a
potential solution does or does not meet it.

I believe that we explicitly want to state that an IPv6 site
multihoming solution must allow TCP connections to survive when
a link to the IPv6 Internet goes down, at long as at least one of 
the site's links to the IPv6 Internet remains up.  This 
functionality can require changes to the IPv6 host stack.

We also need to state that existing IPv6 implementations should
be able to establish new connections, and Brian stated so well.


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

This section contains no requirements.  Are there any requirements that
follow from this section?  Are we requiring that an IPv6 site multihoming
solution provide mechanisms for load sharing when more than one link is
"live"?  Or just that it not interfere with existing mechanisms?  If
the latter, which mechanisms should it fail to interfere with?

I think that we should state that an IPv6 site multi-homing solution
must not interfere with existing load balancing solutions, such as ??


>3.3 Performance
>
>    One of the reasons for multihoming with two providers is poor
>    connectivity between them. For example, customer C is buying transit
>    from ISP A, and there is long term congestion between ISP A and ISP
>    B. To improve connectivity to ISP B, customer C buys transit from
>    ISB B, thus bypassing the congestion and improving the performance
>    between C and ISP A. 
>
>    Some operators have requirements to provide different grades of
>    connectivity to customers based on network reach, and achieve this
>    objective by grouping customers of similar service grades together,
>    and advertising their networks over separate transit circuits. The
>    result is multihoming for the purpose of transit capacity
>    segregation.

Another good reason to multihome, I guess, but there aren't any requirements
in this section either.  Are you implying a requirement that an IPv6
site multi-homing solution provide a mechanism for "transit capacity
segregation", or only that it will not interfere with existing mechanisms?
If the latter, which mechanisms?  I don't really understand this section
very well -- is the differentiation happening within the site, or 
within the ISP?

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

The last sentence would appear to be a requirement, but it doesn't say
what the requirement actually is...  Would a multihoming proposal need
to include a mechanism for shifting specific traffic between ISPs when
more than one is available?  Or, just not interfere.

Also, when one connection goes down, does the multihoming solution
need to provide some way for the site admin to configure whether the
NNTP traffic (for example) would be re-routed through another 
provider or dropped on the floor?  The customer might prefer that
NNTP sessions fail, rather than paying the higher rate.

>3.5 Availability of Infrastructure
>
>    Sometimes it is not possible to increase transit capacity to a
>    single provider, because that provider does not have sufficient
>    spare capacity to sell. In this case a solution is to acquire
>    additional transit capacity through a different provider. This
>    scenario is common in bandwidth-starved stubs of the network where,
>    for example, transit demand outpaces under-sea cable deployment.

I asked my questions about this one before...  So, what should an
IPv6 multihoming solution do about this?  Is this a requirement for
some sort of configurability?  Or what?


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

Does this paragraph mean to state that a new mechanism must be
no harder to deploy and maintain than an existing mechanism?  Or
is this paragraph proposing an heuristic to select between 
proposals that meet all of the other requirements.  If the former,
it needs definition.  If the latter, it should be in a different
section.

I think that we have discussed several heuristics for a good 
design that could be placed in a separate section:

         - Simplicity (as above).
         - Minimal impact on existing host implementations.
         - Ability to converge on a new information quickly.
         - Others?

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

This is a good requirement, but should probably be more rigorously
defined.

I would also add another major requirement:

Compatibility

The current IPv4 multihoming mechanisms have been widely deployed
because they are compatible with existing IPv4 networking 
implementations and practices.  (Compatible:  The implementation
or practice works at least as well in the presence of multihoming
as it does in a singly-homed site).  

IPv6 site multi-homing must be compatible with (see definition
above):

         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?

I don't have all of the information at my fingertips to generate
this list in real-time, but I'd be happy to work with someone to
put it together.

We have spent 10 years (well, I've only spent 6 years, myself)
developing IPv6, and I think that there are parts of it that we
want to preserve.  We need an IPv6 site mutlihoming solution, and
we are willing to make routing and limited host changes to get one,
but I think that there are things that we are not willing to
sacrifice.  Let's list them!

Again, no offense is meant, and I hope that none will be taken.
But, I think it is important that we do a good job of rigorously
defining our requirements before we begin to evaluate solutions.

Margaret