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

[Ballot comment]
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.

[Ballot comment]
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.
[A tangent from the Discuss, but looks fine]

      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.

[Ballot comment]
>      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/

[Ballot discuss]
Overall this is an excellent discussion, well worth a few tough-going paragraphs. 

Section 7.2, Rehoming Triggers is missing a consideration that the goals for sensitivity
to triggers may be very different depending on the transport.  There's no doubt that any
session would need a trigger to rehome if its path to the locator fails, but for some transports,
moving, and triggering transport-related changes, may be far less desireable than waiting
out the triggering stimulus.  This problem is only partly solved by models with  "an internal signaling
mechanism between the transport stack element and the locator pool management stack
element" because of non-failure triggers coming from other stacks, and because of transport
issues such as use of resource reservation.  Consider the case of a session with reservations
established by RSVP or NSIS, when a routing change has just caused adaptive updates to the
reservation state in a number of elements along its path.  The transport using the path is
likely to see some delays or timeouts, and its reaction to the loss may trigger a locator change,
which is likely to mean another reservation update, and this is high overhead, though
the reservation protocol knows how to do it.  Individual transports probably have to tune
any feedback they give, so that they don't respond to net-interior routing change delays
(not knowing their cause) with a trigger, and then feedback to themselves new routing change
delays as result.  And different transports have rather different behaviors and* hooks for management.

I suggest adding a cautionary, guiding question to the beginning
of Section 7.2, Rehoming Triggers.  Before the first question:

    What triggers are used to identify that a switch of locators is desirable?

Add:  What are common denominator goals of Rehoming Triggers?  What are the
        objectives that triggers conservatively should meet across all types of sessions?

Also, this question should appear, whether as part of the first one, or later, I'm
not sure.  The Editor is a much better writer than I am, for figuring out how to put
these points (or improved versions of them) into the section.

        What state changes within the network path should be triggers for all, and
        are there state changes that are triggers only for selected transport sessions?

Review by Michael Patton, Gen-ART:

Summary: This draft is ready for publication as an Informational RFC

I had two extremely minor comments and a few typos, but on the whole I
found it fairly well explained and comprehensive.  I do have to
disclaim that as one of the group that argued for a separation of
locators and endpoint IDs in the initial IPv6 definition, I'm not
unbiased in this area.



At the end of Section 6.3.4 it notes that "This approach implies that
the active end of a communication needs to cycle through all of its
associated locators as source addresses until it receives a response
or exhausts its locator set."  However, it's worse than that, it needs
to try the full cross product of all of its locators as source as well
as all of the remote's locators as destination.  Of the MxN
combinations, there may only be one that works.


I would suggest that publication of this document and of
draft-ietf-multi6-things-to-think-about should be tied together.  I
also note that this document cites an old version of that other
document.  Additionally, I expect that this needs to be tied to the
security one based on the security section.


Typos:
------

Section 2 (under Endpoint Identity Protocol Stack Element):
"E ndpoint" => "Endpoint"

Section 2 (under Multi-Homed Site):
"one transit providers" => "one transit provider"

Section 3: "particularl" => "particular"

Section 4: "further consideration also include"
=> "further considerations also include"


Section 5.1: "Neither the local or the remote host"
  => "Neither the local nor the remote host"

Section 5.3: "ISP B' address prefix" => "ISP B's address prefix"

Section 5.3: "ISP A vs.  ISP B" => "ISP A vs. ISP B"

Section 6: "pass the reminder of the PDU"
=> "pass the remainder of the PDU"

Section 6.2: "represents a approach" => "represent an approach"

Section 6.2: "in mosts contexts" => "in most contexts"

Section 6.2: "that a the" => "that the"

Section 6.2: "discivered" => "discovered"

Section 6.2: "an open question as how" => "an open question how"

Section 6.3.2: "how is this interaction is to be"
    => "how this interaction is to be"

[Ballot comment]
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.

[Ballot comment]
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?