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

[Lou Berger <[e-mail]>]

Hi David,

Thanks for the response, see below.


----------
On October 8, 2019 10:04:00 AM "Black, David" <[e-mail]> wrote:

> 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.
>

I think there's some cross usage of the term flow here.   DetNet flow 
identification is the traffic classification function that enables 
DetNet to deliver different service, including paths through a network 
to different flows.  ECN markings already impact how packets are handled 
in ECN enabled routers (DROP for 00 for DE packets).  Also, I don't see 
anything in the RFCs that would preclude path selection based on 
different DSCPs or different ECN field values -- It is even covered 
under 'split paths' albeit from the perspective of a broken 
implementation.  As a possible example, I could see ECT and non-ect 
traffic routed over different paths and am not sure where this is 
precluded by the reference RFCs.


> [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?

I'm not sure how we can preclude what operators choose to do.  Vendors 
on the other hand...

How about adding:

It is important to note that the DSCP values used within a DetNet domain 
may not be meaningful outside of that DetNet domain as the values may 
have no relationship to standard PHB and DSCP values.  It is REQUIRED 
that routers that operate in both DetNet and non-DetNet domains support 
remapping or setting the DSCP value of any flow originating in a DetNet 
domain.


>
> 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).
For the MPLS data plane, I suspect this will be required.  For IP, given 
the complexities of ECMP, I don't see how this behavior notably 
complicates OAM, but also agree it will need to be considered.

>
> 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.

sure.  but then it should be using different DSCP values.

Lou

PS WRT your offer to join one of the data plane calls, that would be great!

>
> 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
>> 
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet