Hi, Brian, On Mon, May 8, 2017 at 10:38 PM, Brian E Carpenter < [email protected]> wrote:
> On 08/05/2017 14:41, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-anima-grasp-11: No Objection > ... > > In this text, > > > > T6. The protocol must be capable of supporting multiple > > simultaneous > > operations with one or more peers, especially when wait states > > occur. > > > > I understand every word, but I'm not sure what this requires the protocol > > to do. Are you asking that the protocol be non-blocking? But that's a > > guess. > > The practical implication is that we need session IDs, so that overlapping > operations can be distinguished. It's a bit over-simplified to call it > non-blocking - for example discover/discovery response looks like a > blocking call with timeout in the API, but the underlying messages are > atomic. > Your explanation helped me understand a lot. Could I suggest something like OLD T6. The protocol must be capable of supporting multiple simultaneous operations with one or more peers, especially when wait states occur. New T6. The protocol must be capable of distinguishing multiple simultaneous operations with one or more peers, especially when wait states occur. (using the word "distinguishing" from your explanation that lifted my fog) > > > > In this text, > > > > A GRASP implementation will be part of the Autonomic Networking > > Infrastructure in an autonomic node, which must also provide an > > appropriate security environment. In accordance with > > [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic > > Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. > > > > I wonder what happens if the security environment isn't the ACP. Is that > > obvious? > > Hopefully https://tools.ietf.org/html/draft-ietf-anima-grasp-11# > section-3.5.1 > explains this. > It does, but that nudges me to ask another question. I'm looking at 3.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. and 3.5.1. Required External Security Mechanism The protocol SHOULD always run within a secure Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to carry all messages securely, including link-local multicast when it is virtualized over the ACP. A GRASP instance MUST verify whether the ACP is operational. If there is no ACP, one of the following alternatives applies: Are those SHOULDs saying the same thing using different words? Assuming so ... probably the easiest change that would have clued me in, would be to say (in 3.2) something like 3.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. If there is no ACP, the considerations described in Section 3.5.1 apply. as a forward pointer. You could likely link these two thoughts together in a better way, but I hope you see what I'm suggesting. > > > In this text, > > > > An implementation MUST support use of TCP. > > It MAY support use of another transport protocol. However, GRASP > > itself does not provide for error detection or retransmission. Use > > of an unreliable transport protocol is therefore NOT RECOMMENDED. > > > > just to educate me, is the strategy here, that (for instance) if > > synchronization fails over an unreliable transport protocol, that > > eventually it will be attempted again, just because the two ACAs know > > they aren't synchronized? > > Actually even 'reliable' transports can fail on occasion, so I'd say > that an implementation should *always* wait and retry. UDP just makes > it all harder. > Grrr, but please see below. > > > > > I'm really confused by this text. > > > > Nevertheless, when running within a secure ACP on reliable > > infrastructure, UDP MAY be used for unicast messages not exceeding > > the minimum IPv6 path MTU; however, TCP MUST be used for longer > > messages. In other words, IPv6 fragmentation is avoided. If a node > > receives a UDP message but the reply is too long, it MUST open a TCP > > connection to the peer for the reply. Note that when the network is > > under heavy load or in a fault condition, UDP might become > > unreliable. Since this is when autonomic functions are most > > necessary, automatic fallback to TCP MUST be implemented. The > > simplest implementation is therefore to use only TCP. > > > > We've been having quite the discussion about how well Path MTU Discovery > > works, even in IPv6. Because GRASP could be running over virtual > > interfaces, I suspect there's a chance that you'll be running in a tunnel > > that will give you a Path MTU that's smaller than the IPv6 minimum. But > > ignoring that for now ... > > > > IIRC, we've had poor experiences with protocols that are expected to > > switch from UDP transport to TCP transport in the middle of a > > request/response pair. But, setting THAT aside for now ... > > > > This text correctly points out that UDP transport is most likely to fail > > under heavy network load or in a fault condition, when autonomic > > functions are most necessary. If TCP is mandatory to implement, and > > implementations will need to switch from UDP to TCP at the most awkward > > times, and that's been a problem area for other protocols in the past, > > why not just require TCP in the first place? > > Personally (editor hat off) I would eliminate UDP completely except for > the multicasts, but there are others who believe that UDP has its place. > So I guess this is compromise text. I'll be interested to see if anybody > can make a UDP variant work robustly. > > > > > I see that the UDP/TCP question was listed as an open issue before it was > > closed, so I'm not balloting Discuss, because I assume I'm missing > > something that people will help me understand, but I thought about it for > > a while ... > Continued from "grrr" above ... I'm muttering to myself, "This looks like the working group is choosing to drag the same kind of weird corner cases SIP applications have when they're written to run over both TCP and UDP into 21st century applications, except that these applications can be misconfiguring networks at scale when they get something wrong, rather than just keeping us from completing a VoIP call." Having muttered that to myself, I re-read https://www.ietf.org/iesg/statement/discuss-criteria.html, and can't decide whether I'm muttering about something that's closer to the Discuss criteria "The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity" or the Discuss NON-criteria "Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in preferences among technically sound approaches." Unfortunately, "this is likely to blow up badly" doesn't obviously fall into either bucket. So, I'll leave this as a Comment, and let the many folks who see IESG ballot positions these days think about this, and either tell me that this isn't a problem, or that it is. Several of them have more relevant experience with application protocols that use multiple transports than I do. Alternatively, perhaps providing a DNS-style "TrunCation" indicator (as in https://www.ietf.org/rfc/rfc1035.txt) and letting applications retry using TCP would be useful. But, do the right thing, whether I think it's the right thing or not, of course. > Thanks for this text, > > > > If no discovery response is received within a reasonable timeout > > (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery > > message MAY be repeated, with a newly generated Session ID > > (Section 3.7). An exponential backoff SHOULD be used for subsequent > > repetitions, to limit the load during busy periods. Frequent > > repetition might be symptomatic of a denial of service attack. > > > > and especially for the warning about DoS attacks. > > > > I found Appendix D and E useful. Thanks for including both of them. > > Thanks for the comments. > > Brian > It's always a pleasure :-) Spencer
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
