Last Call Review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

Request Review of draft-ietf-rtgwg-enterprise-pa-multihoming
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-06-04
Requested 2019-05-21
Authors Fred Baker, Chris Bowers, Jen Linkova
Draft last updated 2019-06-04
Completed reviews Rtgdir Last Call review of -07 by Nicolai Leymann (diff)
Genart Last Call review of -08 by Pete Resnick (diff)
Tsvart Last Call review of -08 by Michael Tüxen (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-ietf-rtgwg-enterprise-pa-multihoming-08-genart-lc-resnick-2019-06-04
Posted at
Reviewed rev. 08 (document currently at 12)
Review result Almost Ready
Review completed: 2019-06-04


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


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:


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.