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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
