Architectural Approaches to Multi-homing for IPv6
draft-ietf-multi6-architecture-04

My Discuss issues were handled well.  The draft has a summary of the changes 
reviewed (which will disappear from the RFC version):

      Section 5.1 Multi-Homing: Routing
         Added text relating to the risks to transport layer
         surviveability when routing convergence gnerates unstable
         temporary path states, and takes an indeterminate time to
         complete.
[For Ted's Comment; good new material]

      Section 6.3.1 Triggering Locator Switches
         Added note about different trigger responses being required
         from different transport sessions, arising from IESG review.

      Section 7.2 Rehoming Triggers
         Added questions regarding transport considerations, arising
         from IESG review.

Reviewed by Michael Patton, Gen-ART

Only minor issues found; full review in document comment log.

  In the security considerations, the author points to the "Threats
  relating to IPv6 multi-homing solutions," which is good, but I
  think that this document should also state the implications of
  the potential solutions on IP security (IPsec).  IPsec is
  discussed very briefly in section 6.3.3, but this is not the only
  place concerns arise.

Section 5.1 says:

This approach generally meets all the goals for multi-homing
   approaches with one notable exception: scalability.  Each site that
   multi-homes in this fashion adds a further entry in the global
   inter-domain routing table.  Within the constraints of current
   routing and forwarding technologies it is not clearly evident that
   this approach can scale to encompass a population of multi-homed
   sites of the order of, for example, 10**7 such sites.  The
   implication here is that this would add a similar number of unique
   prefixes into the inter-domain routing environment, which in turn
   would add to the storage and computational load imposed on
   inter-domain routing elements within the network.  This scale of
   additional load is not supportable within the current capabilities of
   the IPv4 global Internet, nor is it clear at present that the routing
   capabilities of the entire network could be expanded to manage this
   load in a cost-effective fashion, within the bounds of the current
   inter- domain routing protocol architecture.

I think transport-layer survivability may not be met here, given
the likely propagation times.  In general, I think this statement above:


   The environment of multi-homing is one that is intended to provide
   sufficient support to local hosts so as to allow local hosts to
   exchange IP packets with remote hosts, such that this exchange of
   packets is to be transparently supported across dynamic changes in
   connectivity. 

captures the problem with using Routing well--propagation delay is such
that dynamic changes in connectivity cannot be handled by the routing
system with any degree of reliability.

For 6.3.1, where would something like SIP's UPDATE command fall?
Is this a transport layer trigger, or an application-layer trigger?

>       The E ndpoint Identity Protocol Stack Element refers to an added
>

typo/space

>       considered.  In the Internet Protocol architecture the LLP of the

s/the/, the/

>    achieve a form of traffic engineering, support for particularl

Run entire document through spell?

>    The major characteristic of this scenario is that the address space
>    used by, and advertised as reachable by, ISP A is distinct from the
>    address space used by ISP B.

At some point, the use of "this scenario" becomes unclear. I don't
understand where the above comes from under "this scenario".

Indeed, it might be better to call this "simple scenario" or "generic
scenario" (or something) and use that throughout rather than "this",
which is more ambigious.

>    inter- domain routing protocol architecture.

space

>    outer level locator packet header is wrapped around the packet as it

s/outer level/outer-level/