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