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

[Lou Berger <[e-mail]>]

Hi David,

Thank you for the comment see in line responses below.


----------
On July 17, 2019 3:51:41 PM "Black, David" <[e-mail]> wrote:

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

I think you had mentioned this before. I'm sorry I didn't catch that it 
hadn't been fixed. believe we also discussed that this is a pretty 
straightforward fix and it just needs to be changed to a list of values.

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

I'm not sure I follow this. My understanding was that the use of ecn should 
be controllable by the detnet controller plane.  I'm sure we can work out 
some language that makes it clear that we have two subfields here to be 
dealt with. perhaps this is a good conversation for our face-to-face 
meeting next week.


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

I think you're implying something settle here that I'm not following. If we 
can qualify this statement to the case that doesn't include the DSCP in 
flow identification.
.

> 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 think this is the qualification I was referring to above. If not, it 
would be helpful if you could clarify.

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

Agreed.

> 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!!").
> 		

Agreed. Any specific text suggestions you have would be appreciated

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