Last Call Review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
review-ietf-rtgwg-enterprise-pa-multihoming-08-genart-lc-resnick-2019-06-04-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08
Reviewer: Pete Resnick
Review Date: 2019-06-04
IETF LC End Date: 2019-06-04
IESG Telechat date: Not scheduled for a telechat

Summary: Almost Ready.

I found this overall to be an excellent document with clear technical
explanations that even an upper-layer knucklehead like me could understand.
However, there a couple of issues could use more discussion. I put them as
"Minor issues", in that they're not showstoppers, but I do think they're
important and hope you'll be able to address them.

Major issues:

None.

Minor issues:

Throughout, but particularly in section 5, this document refers to "hosts"
doing address selection. To be fair, so does RFC 6724, but 6724 is referring to
*default* address selection. In reality, *applications* do address selection on
a host; the host stack will only do address selection if the application
requests a default address. That works well for the scenarios in 6724, but in
this document, for example section 5.2.3, I'm not so sure. The idea that a host
would receive an ICMP destination unreachable and re-arrange its address
selection seems at least an incomplete picture: An application with a (normal,
non-multi-path) TCP connection to a remote application is not able to "try
another source address to reach the destination"; the source address is already
set for that TCP connection, so the only choice is to close the connection
entirely. If the application chooses to re-establish the connection with a
default address, yes, the host stack could then give a new default address back
to the application, but this is hardly the dynamic and quickly adjusting
process that the document seems to be envisioning.

I don't think the above invalidates the core of the document or requires some
grand rewrite. But I do think some clarification is in order, saying that the
mechanisms described help with the *default* address selection, and some short
discussion of the limitations for what applications can (and more importantly
cannot) do with these mechanisms would be useful.

My suspicion is that section 7.3 underestimates the availability (current and
future) of multipath transport. Apple is using it now in production, and Linux
already has it in their implementation. I think this is actually a reasonable
possible solution in the future, and I would be a little more optimistic than
the WG in this section.

Nits/editorial comments:

Two editorial bits in section 1:

   This document defines routing requirements for enterprise multihoming
   using provider-assigned IPv6 addresses.  We have made no attempt to
   write these requirements in a manner that is agnostic to potential
   solutions.  Instead, this document focuses on the following general
   class of solutions.

Is that second sentence right? If you are giving a general class of solutions,
that seems agnostic to the particular solution. Just a bit confusing.

   A host SHOULD be able respond dynamically...

Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.