Hi Pete, Thanks for reviewing the draft - not the shortest one...;)
On Wed, Jun 5, 2019 at 1:42 AM Pete Resnick via Datatracker <nore...@ietf.org> wrote: > I found this overall to be an excellent document with clear technical > explanations that even an upper-layer knucklehead like me could understand. > However, there a couple of issues could use more discussion. I put them as > "Minor issues", in that they're not showstoppers, but I do think they're > important and hope you'll be able to address them. > > Minor issues: > > 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. Oh. Very good point - looks like I assumed that it's obvious and did not mention it anywhere explicitly. Yes, all address selection processes mentioned are for new connections. And indeed the applications/upper-layers could override the default address selection algorithm.. I've added some text to clarify. In particular: 1) Section 6: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#page-24 First we look at how a host is currently expected to select the source and destination address with which it sends a packet for a new connection. 2) Section 6.1 https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.1 "It should be noted that [RFC6724] defines the default behaviour for IPv6 hosts. The applications and uppler-layer protocols can make their own choices on selecting source addresses. However 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." > 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. I've added Section 6.7 - Solution Limitations https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.7 If you could review and let me know if it addresses your concern, it would be great! > My suspicion is that section 7.3 underestimates the availability (current and > future) of multipath transport. Apple is using it now in production, and Linux > already has it in their implementation. I think this is actually a reasonable > possible solution in the future, and I would be a little more optimistic than > the WG in this section. I've added "(even if new releases of operating systems get multipath protocols support there will be a long tail of legacy hosts)." to clarify my lack of optimism.. > Nits/editorial comments: > > Two editorial bits in section 1: > > This document defines routing requirements for enterprise multihoming > using provider-assigned IPv6 addresses. We have made no attempt to > write these requirements in a manner that is agnostic to potential > solutions. Instead, this document focuses on the following general > class of solutions. > > Is that second sentence right? If you are giving a general class of solutions, > that seems agnostic to the particular solution. Just a bit confusing. Updated. > > A host SHOULD be able respond dynamically... > > Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone. Fixed, thanks! -- SY, Jen Linkova aka Furry _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
