Thank for the questions! Please see responses inline:
> * How do you propose the populated data to be handled normally? Will > the probe destination (i.e., the dest address of the UDP packet) be > expected to understand these, or will loopback mode have to be used? > The reason I ask is that I'm not sure what happens if all nodes in the > network do not support this probe. Could this give more network insight > to the destination, and thus be a security weakness? One of the main reasons to use regular data packet and not any special OAM format or IPv6 extension header is to let the packet pass through non-compliant devices transparently. The device that understand the request will fill in their data, but others will remain invisible (unless hop-by-hop variant is requests using router-alert option - but I doubt this would be viable given the state of hardware in the DC at the moment). For security concerns: this is a rather big topic in context of data-plane probe, and I haven't completed the section yet. Easy way out is saying "we control the network in DC and we are aware of security consequences of disclosing the device state". The header marker might help here - a random key value would need to be guessed by possible attacker. In addition, only select applications could be allowed to send the probes to the "special" port. > * Related to the question above what would happen if a set a hop count > of four, but the fourth device (before my destination) has not awareness > of this telemetry system? The responsibility for setting the right hop limit is on the sender. It needs to be aware there are devices that do not understand the form of signaling, and adjust hop-limit respectively. All non-compliant hops will be transparent. Worst case, if sender was clueless, the packet will just fall through to the other side just like a regular active probe. > * Why not use ifIndex values for port IDs? It seems to me that having a > more standard and known cross-vendor way to identify ports is useful. This is a good idea: I heard this a few times already and I will change the spec accordingly :) It is hard to number the physical ser/des (e.g. BRCM has a way to do this in SDK, but others would likely be different). The tradeoff is that the ifIndex will need to be stored in some state table in hardware. >* You do not list IANA considerations, but it seems to me that your >probe types would be well-suited for a registry that perhaps could live >with IANA? It would also be useful to have some reserved space for > private extensions where possible. I wasn't sure what kind of code-point could be requested. I think this is a very good point for "Type" registration, to ensure better interop. > * I think you mentioned it at the mic, but the draft doesn't really > address what happens if a device supports this telemetry system, but > does not support a specific probe type? For example, what if I define > type 50 down the road, but not all of my devices/hardware yet support > this? What happens then? Right now the idea is that device will simply set the bit signaling that it does not understand the requested type, and leave the value in TLV empty (zero). The length is known to the device even if it does not understand the type. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
