Hi Jen,
Thanks for the additional updates. A few comments inline.
On 3 Jul 2019, at 20:07, Jen Linkova wrote:
Again, hosts pick default addresses for applications to use, and
applications pick the addresses that packets will use.
OK, I guess we are just using different terminology here...
For me 'a host' is a whole element connected to the network, including
all subsystems and applications running.
Until your email I was thinking about an application as an element of
a host. If I got you right, when the draft says 'host' you read it as
'network stack on a host', right?
Well, yes, to a certain extent. But my point here was a bit different:
Even if we call it "the network stack on a host", it isn't picking the
addresses that packets will use, at least not on a packet-by-packet
basis. That gets back to the point about dynamic updates: Even if the
host stack were to change its mind about which the correct address is,
that host isn't using that new address for packets unless/until
currently running apps shut down their existing connections and make new
ones. They're using the old address until doing so actually fails, and
then only if they reinitiate communications. The "stack" can't change
that, it can only suggest to the upper layers that they stop using what
they're currently using. (You've talked about this in the new paragraph
in 6.)
How about this? :
"It should be noted that [RFC6724] only defines the behavior of IPv6
hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make
their
own choices on selecting source addresses. The mechanism proposed in
this document attempts to..."
I've updated that paragraph:
"It should be noted that [RFC6724] only defines the behavior of IPv6
hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make
their own choices on selecting source addresses. The mechanism
proposed in this document attempts to ensure that the subset of source
addresses available for applications and upper-layer protocols is
selected with the up-to-date network state in mind. The rest of the
document discusses various aspects of the default source address
selection defined in [RFC6724], calling it for the sake of brevity
"the source address selection".
I hope that the last sentence makes the rest of the document less
confusing.
What do you think?
Yes, that'll be OK.
I'd also suggest taking a look through the rest of section 6 for use
of
the word "host" and see if the word "default" needs to be inserted
somewhere after it (like "...hosts to choose the correct *default*
source address"), or if it needs to be changed to "application".
I've updated a number of places as well.
There are still quite a few places that I would change in section 6, but
I'll leave it to Alissa to decide which (if any) are really worth diving
into. I think now you understand what I'm trying to get at.
Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as
another mechanism (in addition to BGP) to deal with the problem.
It is there:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3
Sorry, I wasn't clear: I meant it would be nice if there reference in
6.7.1 to section 8.3, or a mention in 6.7.1 of MPTCP in addition to its
mention of BGP.
My suspicion is that section 7.3 underestimates the availability
(current and
future) of multipath transport.
You can have the half empty glass; I'll take the half full one. ;-)
As per Magnus's suggestion, I've updated the text to mention that
PA-based multihoming and MP transport could benefit from each other:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3
Fair enough.
Thanks again for the updates. As the boilerplate for the review says,
wait for instructions from your AD for further guidance, particularly in
order to address Alissa's DISCUSS.
pr
--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best
