Comment: As specified in the current draft, the DetNet IP data plane does not support ping, traceroute, and any other mechanism or tool that is based on ICMP. This is because ICMP does not use ports, so ICMP traffic cannot be described by either a 5-tuple or a 6-tuple, and hence ICMP traffic cannot be part of a DetNet flow that is described by a 5-tuple or 6-tuple. The draft needs to be revised to either: - enable ICMP to be used with the DetNet IP data plane (ICMP would use a 3-tuple, two IP addresses and the protocol number for ICMP); or - document and justify a deliberate design decision that ICMP (and hence ICMP-based tools) cannot be used with the DetNet IP data plane. The former course of action (enable ICMP with the DetNet IP data plane) is strongly suggested, e.g., in order to enable use of ping and traceroute with the DetNet IP data plane. Background: In discussion at the Singapore detnet WG meeting, OAM was characterized as something that would be added to the DetNet data planes later, with the (at least implied) assertion that there shouldn't be anything in the data planes that blocks OAM functionality. That does appear to be the case for the MPLS data plane, but the IP data plane appears to differ. Later than might have been ideal, I've discussed DetNet IP OAM with Greg Mirsky via email - our initial take from that discussion is that most OAM for the DetNet IP data plane can be accomplished over UDP, with the notable exception of tools such as ping and traceroute that use ICMP. For ping and traceroute to work with DetNet, the ICMP packets that are used have to pass through the DetNet data plane at DetNet nodes, otherwise these tools may erroneously report no connectivity problems with the ordinary (non-DetNet) data plane when DetNet IP data plane connectivity is broken and vice-versa. Sorry to bring this up at a late stage in the process, but better late than never. I also spotted an editorial oversight in Section 4.3.1: OLD Class of Service (CoS) for DetNet flows carried in IPv6 is provided using the standard differentiated services code point (DSCP) field [RFC2474] and related mechanisms. NEW Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is provided using the standard differentiated services code point (DSCP) field [RFC2474] and related mechanisms. The authors deserve some sort of recognition here, as the far more typical variant of this oversight is to omit IPv6 :-) Thanks, --David > -----Original Message----- > From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG > Sent: Friday, February 28, 2020 3:59 PM > To: IETF-Announce > Cc: Ethan Grossman; detnet@xxxxxxxx; draft-ietf-detnet-ip@xxxxxxxx; > db3546@xxxxxxx; detnet-chairs@xxxxxxxx > Subject: Last Call: <draft-ietf-detnet-ip-05.txt> (DetNet Data Plane: IP) to > Proposed Standard > > > [EXTERNAL EMAIL] > > > The IESG has received a request from the Deterministic Networking WG > (detnet) > to consider the following document: - 'DetNet Data Plane: IP' > <draft-ietf-detnet-ip-05.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@xxxxxxxx mailing lists by 2020-03-13. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document specifies the Deterministic Networking data plane when > operating in an IP packet switched network. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
