Re: [Detnet] consolidated response: IP Data Plane draft comments

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

Lou,

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

The proposed text does not address the comments.

[A] ECN

The proposed text effectively ignores the comments, and fails to address the problem.

The ECN field MUST NOT be used for flow identification, period (e.g., see RFC 3290, which does not include ECN in the 6-tuple).  In particular, it would be wrong for two DetNet flows to differ solely on the values used in the ECN field.  If there's a disagreement, please cite text from RFC 3168 that justifies this proposed ECN field usage.

[B] 5-tuples and 6-tuples

As I noted in one of the referenced messages in response to a question:

> > Are you okay with dropping "While 5-tuples suffice to identify DetNet flows,"
> Not by itself - if that text is dropped, I'd want to add a couple of sentences
> (perhaps not in Section 3) to explain how DetNet flows differ from Diffserv flows,
> i.e., "microflows" in defined in RFC 2475 (Diffserv Architecture).

The heads up for everyone is that if multiple DetNet flows differ only in DSCP (i.e., IP addresses, transport protocol and ports are the same), then non-DetNet network management tools that deal with traffic flows will lump those flows together.  Is it at least possible to prohibit (or at least strongly discourage, i.e., "SHOULD NOT") use of the same 5-tuple for DetNet and non-DetNet traffic?  That would at least contain the resulting network management and operational effects to DetNet?

The use of DSCP for flow identification makes the OAM problem much harder for the IP data plane by dramatically increasing the difficulty of getting DetNet IP OAM traffic to fate-share with the DetNet traffic for which the OAM functionality is intended (it may be necessary to resort to shoving an MPLS label in there to identify OAM traffic and requiring nodes that originate or terminate DetNet OAM packets to understand enough of MPLS to deal with this).

Also, be aware that if two DetNet flows differ only in DSCP, most existing network transport protocols will have problems dealing with that situation - see RFC 7657 for details.

Thanks, --David

> -----Original Message-----
> From: Lou Berger <[e-mail]>
> Sent: Sunday, October 6, 2019 4:47 PM
> To: Black, David
> Cc: [e-mail]
> Subject: consolidated response: IP Data Plane draft comments
> 
> 
> [EXTERNAL EMAIL]
> 
> 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
>