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

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

If it helps, I'll be happy to join one of the Monday calls on the data plane drafts to discuss this further.

Thanks, --David

> -----Original Message-----
> From: Black, David <[e-mail]>
> Sent: Tuesday, October 8, 2019 10:03 AM
> To: Lou Berger
> Cc: [e-mail]; Black, David
> Subject: RE: consolidated response: IP Data Plane draft comments
> 
> 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/ykpI6gbH2L705BBjmHbnsZraxi
> g
> >
> https://mailarchive.ietf.org/arch/msg/detnet/phi4OBWijlp7T4_HML2YvWfoa
> as
> >
> https://mailarchive.ietf.org/arch/msg/detnet/th2Yj5Z4_8VtBsEOF1UfLejMh
> pM
> > 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
> >