Jen, thanks for the updates. Pete, thanks for your response. I cleared my DISCUSS. Cheers, Alissa > On Jul 3, 2019, at 10:58 PM, Pete Resnick <resnick@xxxxxxxxxxxx> wrote: > > 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 > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
