Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt

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

I think this is about ready to ship. Just a few points, essentially
editorial except for the very last one.

> Abstract
>
> Site-multihoming, i.e. connecting to more than one IP service
> provider, is an essential component of service for many sites which
> are part of the Internet.  Existing IPv4 site-multihoming practices
> provide a set of capabilities that it would ideally be accommodated
> by the adopted site-multihoming architecture in IPv6, and a set of
> limitations that must be overcome, relating in particular to
> scalability.

The second sentence is very hard to understand, contains at least one
grammatical error, and distracts from the main message. I would simply
delete it.

...
> 3.2.2 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
s/must/should/
>    separate functions added to existing functions.
> 
>    Such changes should not prevent normal single-homed operation, and
>    routers implementing these changes must be able to interoperate fully
s/must/should/
>    with hosts and routers not implementing them.
> 
> 3.2.3 Impact on Hosts
> 
>    The solution should not destroy IPv6 connectivity for a legacy host
>    implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other basic
s/2373/3513/
>    IPv6 specifications current in November 2001. That is to say, if a
s/November 2001/April 2003/
>    host can work in a single-homed site, it must still be able to work
s/must/should/
>    in a multihomed site, even if it cannot benefit from
>    site-multihoming.
> 
>    It would be compatible with this requirement for such a host to lose
s/requirement/goal/
>    connectivity if a site lost connectivity to one transit provider,
>    despite the fact that other transit provider connections were still
>    operational.

...

> 3.2.7 Multiple Solutions
> 
>    There may be more than one approach to multihoming, provided all
>    approaches are orthogonal (e.g. each approach addresses a distinct
s/(e.g./i.e./
>    segment or category within the site multihoming problem. Multiple
>    solutions will incur a greater management overhead, however, and the
>    adopted solutions SHOULD attempt to cover as many multihoming
s/SHOULD/should/
>    scenarios as possible.
s/scenarios/scenarios and goals/

> 
> 4. Security Considerations
> 
>    A multihomed site should not be more vulnerable to security breaches
>    than a traditionally IPv4-multihomed site.
 
Should we add "or a single-homed IPv6 site"?

    Brian