[Detnet] consolidated response: IP Data Plane draft comments

[Lou Berger <[e-mail]>]

David,

     My apologies on the time to get back to this topic.  Before the 
last IETF you raised a number of points on the IP data plane document.  
For context, I believe the threads are found in:
https://mailarchive.ietf.org/arch/msg/detnet/ykpI6gbH2L705BBjmHbnsZraxig
https://mailarchive.ietf.org/arch/msg/detnet/phi4OBWijlp7T4_HML2YvWfoaas
https://mailarchive.ietf.org/arch/msg/detnet/th2Yj5Z4_8VtBsEOF1UfLejMhpM
https://mailarchive.ietf.org/arch/msg/detnet/qvs-S0Nrm1B8w8JYO7zDLFwpTFQ

In re reviewing the discussions, I think we missed the ECN field. Based 
on this and a general reread, I have put together a proposed set of 
changes to the published draft.  The changes are  available at

https://github.com/detnet-wg/data-plane-drafts/commit/d3a733556804f11abbedbd128e3c62786418ddc8

(text format can be received at 
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/ip-tos-update/ip/draft-ietf-detnet-ip.xml)

the following changes are proposed:
OLD183,195c185,202
<    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].  Specifically 6-tuple is
<    (destination address, source address, IP protocol, source port,
<    destination port, and differentiated services (DiffServ) code point
<    (DSCP).  General background on the use of IP headers, and 5-tuples,
<    to identify flows and support Quality of Service (QoS) can be found
<    in [RFC3670].  [RFC7657] also provides useful background on the
<    delivery of DiffServ and "tuple" based flow identification.
<    Referring to a 6-tuple allows DetNet nodes to forward packets with
<    the 6-tuple as is or remap the DSCP where required by the DetNet
<    service.
NEW
 >    The DetNet IP data plane primarily 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]. Specifically
 >    6-tuple is (destination address, source address, IP protocol, source
 >    port, destination port, and differentiated services (DiffServ) code
 >    point (DSCP).  General background on the use of IP headers, and
 >    5-tuples, to identify flows and support Quality of Service (QoS) can
 >    be found in [RFC3670].  [RFC7657] also provides useful background on
 >    the delivery of DiffServ and "tuple" based flow identification.
 >
 >    The DetNet IP data plane also allows for optional matching on two
 >    additional data fields.  The optional fields are the ECN Field, as in
 >    [RFC3168], and the IPv6 flow label field, as defined in [RFC8200].
 >
 >    Generally the fields used in flow identification are forward
 >    unmodified but modification is allowed, for example to a DSCP value,
 >    when required by the DetNet service.

OLD
<    masks, prefixes and ranges.  IP tunnels may also be used to support
NEW
 >    masks, lists, prefixes and ranges.  IP tunnels may also be used to

OLD
437,438c444,446
<    of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code,
<    uniquely identifies a DetNet service flow.
NEW
 >    of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
 >    previously mentioned two optional fields, uniquely identifies a
 >    DetNet service flow.

OLD
590,593c598,608
<    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.
NEW
 >    MUST support list based matching of DSCP values, where the list is
 >    composed of possible field values that are to be considered when
 >    identifying a specific DetNet flow.  Implementations SHOULD allow for
 >    this field to be ignored for a specific DetNet flow.
 >
 >    Implementations of this document MUST allow the ECN field to be
 >    ignored as part of DetNet flow identification. Additionally,
 >    implementations SHOULD support identification of DetNet flows based
 >    on the value carried in the ECN field.  When this field is used to
 >    identify a specific DetNet flow, implementations MUST support a list
 >    of ECN values that match a specific slow.

OLD
705c720,729
<    o  IPv4 Type of Service and IPv6 Traffic Class Fields.
<
<    o  IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
<       zero (0) effectively means that theses fields are ignored.
NEW
 >    o  For the IPv4 Type of Service and IPv6 Traffic Class Fields:
 >
 >       *  If the DSCP field is to be used in flow identification.
 >          Ignoring the DSCP filed is optional.
 >
 >       *  When the DSCP field is used in flow identification, a list of
 >          field values that may be used by a specific flow.
 >
 >       *  If the ECN field is to be used in flow identification.
 >          Matching based on ECN filed values is optional.
 >
 >       *  When ECN field is used in flow identification, a list of field
 >          values that may be used by a specific flow.

Please let me know if this addresses all your comments in an acceptable 
fashion or if you'd like to discuss further.

(BTW I think this is the sole open set of issues on the document.)

Thank you!

Lou