Re: Alissa Cooper's Discuss on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with DISCUSS and COMMENT)

[Jen Linkova <[e-mail]>]

Hi Alissa,

The Gen-ART review comments have been addressed (see "Genart last call
review of draft-ietf-rtgwg-enterprise-pa-multihoming-08" thread).
Please let me know if anything is needed from my side.
Thanks!

On Thu, Jun 27, 2019 at 5:43 AM Alissa Cooper via Datatracker
<[e-mail]> wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-rtgwg-enterprise-pa-multihoming-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'd like to discuss the following comments from the Gen-ART reviewer:
>
> "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."
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please respond to the remainder of the Gen-ART review.
>
>


-- 
sincerely yours,
Jen Linkova a.k.a Furry
Network Engineer