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

[Alissa Cooper via Datatracker <[e-mail]>]

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.