Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
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@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
Hi Pete, On Tue, Jul 2, 2019 at 8:47 AM Pete Resnick wrote: > It's not just that the address selection is for new connections, though > that is certainly true. It's also the question of who is doing what: > Hosts figure out the address for default address selection, and > applications are the ones that do the selecting (whether it is to choose > the host default or choose a different one). Part of what the document > is missing is use of the word "default", at least in a few places. So, > in -09, a couple of suggestions: > > In the Abstract, change "select appropriate source addresses" to "select > appropriate default source addresses". Done! > In the Introduction, you have: > > Section 6 discusses existing and proposed > mechanisms for hosts to select the source address applied to > packets. > It also discusses the requirements for routing that are needed to > support these enterprise network scenarios and the mechanisms by > which hosts are expected to select source addresses dynamically > based > on network state. > > Hosts definitely don't select the source address to be applied to any > given packet; that's (at best) an application thing. Also, "dynamically" > here seems to imply "during the life of the connection", but that's > certainly not what you meant. Something like this seems better: > > Section 6 discusses existing and proposed mechanisms for hosts to > select the default source address to be used by applications. > It also discusses the requirements for routing that are needed to > support these enterprise network scenarios and the mechanisms by > which hosts are expected to update default source addresses based > on network state. Done, thanks for suggesting the text. > 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? > 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? > 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. > 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 > >> 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 -- SY, Jen Linkova aka Furry ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnssd-push-20
On Jul 3, 2019, at 10:45 AM, Robert Sparks wrote: > And I think that's a problem. > > What does a NOTIMP mean to the client? Most of the draft says "The server > doesn't implement DSO". It doesn't say "doesn't implement DSO for this > particular set of bits in this query". Section 6.2.2 says the client should > assume a retry delay of 1 hour before talking to the server (the resolver) > again. > > Now, other parts of the document imply "for this particular set of bits" - in > the overview, near the bottom of page 5, it says to use NOTIMP (actually it > says NOTIMPL, maybe those are different things and I'm confused?) if a > message is received for a class other than "IN" and the server has only > implemented push for "IN". Again, that "assume a retry delay" kicks in. Robert, first, thanks for doing a really thorough review of this document. This is much appreciated. This particular insight is one that I think is really important. I think your initial take on this is correct: if a resolver receives NOTIMP or DSONI from upstream, what this means is “fail,” not “not implemented,” from the perspective of the resolver. The resolver knows what the client is asking, and can’t do it. That’s SERVFAIL, not NOTIMP or DSONI. I think your subsequent point about terminating connections is also correct: we do not want a billion broken clients hammering on servers. However, the DSO document actually specifies how to deal with this: the server can tell the client to shut up for a period of time, and this is explicitly recommended for situations like this. The advantage of failing in cases like this is that it causes the implementation to not work, which then motivates the implementor to fix it. And thanks for the advice about how to terminate TLS connections—I had missed that nuance. Are TLS implementations actually able to do this (to reject RST packets)? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnssd-push-20
On 7/2/19 4:24 PM, Tom Pusateri wrote: On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker wrote: Issue: The discussion of recursive resolvers in section 6.1 may need additional consideration. In particular, the recommendation to pass a received error code along to a client has, I think, some unintended consequences for the client. If the recursive server receives a NOTIMP, for example, passing that to the client tells the client the wrong thing about the server it is connected to. Perhaps it would be better for the recursive server to return SERVFAIL in this circumstance? (Similar to what it would do if it couldn't connect to the next server as described at the bottom of page 10). The only time NOTIMP is returned is in the case where DSO stateful operations (over which DNS PUSH runs) is not supported. This error code is due to the fact that DSO uses a different Opcode than the standard Query/Response Opcode. DSO defines a new opcode. The effect of this is that NOTIMP is the correct response if a server doesn’t support the new Opcode. Similarly, if DSO is supported but DNS Push TLV type is not supported, we return a new RCODE for DSO type not implemented DSOTYPENI. These are both required by existing specifications. If a client begins the connection with a DSO Keepalive to a resolver and the resolver accepts the connection, subsequent SUBSCRIBE operations that return NOTIMP will be obvious that the authoritative server does not support DSO. However, if the client begins with a SUBSCRIBE and receives NOTIMP from the resolver, it’s not clear if the NOTIMP was originated by the resolver or the authoritative server. And I think that's a problem. What does a NOTIMP mean to the client? Most of the draft says "The server doesn't implement DSO". It doesn't say "doesn't implement DSO for this particular set of bits in this query". Section 6.2.2 says the client should assume a retry delay of 1 hour before talking to the server (the resolver) again. Now, other parts of the document imply "for this particular set of bits" - in the overview, near the bottom of page 5, it says to use NOTIMP (actually it says NOTIMPL, maybe those are different things and I'm confused?) if a message is received for a class other than "IN" and the server has only implemented push for "IN". Again, that "assume a retry delay" kicks in. Right now, we allow either DSO TLV to setup the state. In the case that the client begins with a SUBSCRIBE and the resolver returns NOTIMP, the client should attempt a connection with the authoritative server directly as described in 6.1. If the authoritative server returns NOTIMP, then PUSH notifications are not possible. But there's fate sharing, at least as I'm reading the document now. That resolver could have been authoritative (or could reach an authoritative server) for some other subscription. But you've told the client that it's not ok to talk to this resolver for any subscription (for an hour at least). While we could be more explicit about every error case, I don’t think the document says anything wrong here. And I used NOTIMP as an example. I think there may be fate sharing issues with other response codes as well. Thanks, Tom ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
