[Detnet] Diffserv concerns wrt: draft-ietf-detnet-ip-01.txt

["Black, David" <[e-mail]>]

Found a few things that need attention in this draft.

[1] First, a "MUST fix" in Section 5.1.1.4:

5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   These fields are used to support Differentiated Services [RFC2474]
   and Explicit Congestion Notification [RFC3168].  Implementations of
   this document MUST support DetNet flow identification based on the
   IPv4 Type of Service field when processing IPv4 packets, and the IPv6
   Traffic Class Field when processing IPv6 packets.  Implementations
   MUST support bitmask based matching, where bits set to one (1) in the
   bitmask indicate which subset of the bits in the field are to be used
   in determining a match.  Note that all bits set to zero (0) value as
   a bitmask effectively means that these fields are ignored.

That won't fly, as using a DSCP bitmask conflicts with this paragraph in
Section 3 of RFC 2474 (https://tools.ietf.org/html/rfc2474#section-3):

   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop
   behaviors.

The draft's text starting from "Implementations MUST" through the
end of that paragraph needs to be rewritten to align with RFC 2474.

[2] Second, a smaller "MUST fix" in Section 6, where this:

   o  IPv4 Type of Service and IPv6 Traffic Class Fields.

is listed as part of the Management and Control information.  That
item needs to be changed to specify only the 6-bit DSCP portions of
those fields (see RFC 2474), otherwise the DetNet Management and
Control functionality may get confused by the ECN info that is in the
other two bits of those IP header fields.  The ECN info should be
masked off and not visible to DetNet management and control. 

[3] Finally, some clarification on 6-tuple is in order, starting from
this text in Section 3 (DetNet IP Data Plane Overview):

   The DetNet IP data plane uses "6-tuple" based flow identification,
   where 6-tuple refers to information carried in IP and higher layer
   protocol headers.  The 6-tuple referred to in this document is the
   same as that defined in [RFC3290].

That text is fine as far as it goes, but I see a couple of additional
considerations:

a) Each 5-tuple (i.e., 6-tuple without DSCP) can be used for at most one
    DetNet flow, i.e., the flow identifications of any two separate DetNet
    flows MUST differ in at least one component of the 5-tuple (or MUST
    NOT differ only in the DSCP).

b) There are Diffserv situations in which a single flow can use multiple
    6-tuples that differ only in DSCP.  Diffserv AF (Assured Forwarding) is
    the important example, see RFC 2597.

I believe that text needs to be added to make a) clear.  Section 4.3.2
(Quality of Service) to avoid cluttering up the overview in section 3.

The situation in b) is different, and I think b) can be characterized as
inapplicable to DetNet, as the only important Diffserv example is
multiple AF drop precedences - multiple drop precedences make no
sense in a DetNet flow that never experiences drops if the network is
functioning correctly.   It would help to add a sentence somewhere to
state this and that use of  multiple AF drop precedences in a single
DetNet flow is prohibited.  Again, Section 4.3.2 looks like a good place
to do that.

The possible use of multiple drop precedences gets more "interesting"
if multiple drop precedences need to be supported end-to-end in
order to affect drop treatment of a flow in the non-DetNet portion of
the flow's network path, but I would hope that this idea is simply out
of scope for DetNet as a "Doctor, it hurts when I do this" topic (i.e.,
the response is "Don't do that!!").
		
Thanks, --David

> -----Original Message-----
> From: detnet <[e-mail]> On Behalf Of internet-
> [e-mail]
> Sent: Monday, July 1, 2019 2:32 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Detnet] I-D Action: draft-ietf-detnet-ip-01.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Deterministic Networking WG of the IETF.
> 
>         Title           : DetNet Data Plane: IP
>         Authors         : Balázs Varga
>                           János Farkas
>                           Lou Berger
>                           Don Fedyk
>                           Andrew G. Malis
>                           Stewart Bryant
>                           Jouni Korhonen
> 	Filename        : draft-ietf-detnet-ip-01.txt
> 	Pages           : 22
> 	Date            : 2019-07-01
> 
> Abstract:
>    This document specifies the Deterministic Networking data plane when
>    operating in an IP packet switched network.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-detnet-ip-01
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-ip-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet