Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

Pete, thank you for your review. I entered a DISCUSS ballot on the basis of your first point.

Alissa

> On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Pete Resnick
> Review result: Almost Ready
> 
> 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.
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art