Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-detnet-ip-04.txt

From: Balázs Varga A <[email-masked]>
Date: Tue, 7 Jan 2020 14:38:23 +0000

Hi Stig,
Thanks for the review comments/nits.
Sorry for the delay caused by the holiday season,
I will be back with responses soon.
Many thanks & Cheers
Bala'zs

-----Original Message-----
From: Stig Venaas <[email-masked]> 
Sent: Saturday, December 21, 2019 2:33 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RtgDir review: draft-ietf-detnet-ip-04.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-detnet-ip-04.txt
Reviewer: Stig Venaas
Review Date: 2019-12-20
IETF LC End Date:
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
The document is fairly easy to read and of good quality. But I still have some very minor issues that I think need to be resolved. There are also some nits. I'm not that familiar with DetNet, some things might be more clear if familiar with the technology.

Major Issues:
No major issues found.

Minor Issues:
In section 3:
It is slightly confusing that the text discusses 6-tuples, and then references RFC 3670 regarding 5-tuples. It would be good to mention how the 6-tuples here relate to the 5-tuples in RFC 3670.

It says:
   Note: The sub-network can represent a TSN, MPLS or IP network
   segment.

This document only covers IP, right? Or does it cover IP with these sub-network technologies as well? I don't know if it is is good to list the other options here. Perhaps new ones may be added later in other ocuments? Maybe rephrase it so they are examples rather than a complete list?

In section 4.1:
   In order to maximize reuse of existing mechanisms, DetNet-aware
   applications and end systems SHOULD NOT mix DetNet and non-DetNet
   traffic within a single 5-tuple.

Should this be 6-tuple? If not, please be specific what the 5-tuple is here. Same as in RFC 3670? I see the 5-tuple is also mentioned at the end of section 4.2.

In section 4.2:
   As a general rule, DetNet IP domains need to be able to forward any
   DetNet flow identified by the IP 6-tuple.  Doing otherwise would
   limit the number of 6-tuple flow ID combinations that could be used
   by the end systems.  From a practical standpoint this means that all
   nodes along the end-to-end path of DetNet flows need to agree on what
   fields are used for flow identification, and the transport protocols
   (e.g., TCP/UDP/IPsec) which can be used to identify 6-tuple protocol
   ports.

What does protocol ports mean? Is it which transport protocol includes the source and destination port number in the 6-tuple? This should be rephrased I think, since e.g. IPsec SPI may be used. I guess you may be saying that the SPI indirectly identify the ports?

Nits:
In section 1:
layer is used to provides
                  ^^^^^^^
In 2.2.  Abbreviations
It seems random which ones have a period at the end. I'm sure the RFC Editor can help, but maybe add or remove it everywhere?

Section 5.3:
   Implementations if this document
Should be of      ^^^^

Some references are outdated according to idnits.

Regards,
Stig

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Jan 2020 11:12:50 -0500

Hi,

     Thank you for the comments.  Please see below for specific responses.

Changes related to your comments can also be found at 
https://github.com/detnet-wg/data-plane-drafts/pull/70/files

BTW I'm responding as a document contributor.

On 12/20/2019 8:33 PM, Stig Venaas wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> The document is fairly easy to read and of good quality. But I still
> have some very minor issues that I think need to be resolved. There
> are also some nits. I'm not that familiar with DetNet, some things
> might be more clear if familiar with the technology.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
> In section 3:
> It is slightly confusing that the text discusses 6-tuples, and then
> references RFC 3670 regarding 5-tuples. It would be good to mention
> how the 6-tuples here relate to the 5-tuples in RFC 3670.

Does the addition of the final sentence address this comment:

     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.  Note
     that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
     component.

> This document only covers IP, right? Or does it cover IP with these
> sub-network technologies as well? I don't know if it is is good to list
> the other options here. Perhaps new ones may be added later in other
> ocuments? Maybe rephrase it so they are examples rather than a complete
> list?

Here's the proposed revised text.

         Note: The sub-network can represent a TSN, MPLS network or other
         network technology that can carry DetNet IP traffic.

> Should this be 6-tuple? If not, please be specific what the 5-tuple
> is here. Same as in RFC 3670? I see the 5-tuple is also mentioned at
> the end of section 4.2.

We believe this clarified by the first change mentioned above. Note we 
don't see this document as the authoritative source of the 5-tuple 
definition, we're merely trying to use that quite mature definition.

> What does protocol ports mean? Is it which transport protocol includes the
> source and destination port number in the 6-tuple? This should be rephrased
> I think, since e.g. IPsec SPI may be used. I guess you may be saying that
> the SPI indirectly identify the ports?

You're right, this is unnecessary and confusing language. We propose the 
following revision as the way to address your comment:

         From a practical standpoint this means that all nodes along the 
end-to-end path of DetNet flows need....
OLD
           to agree on what fields are used for flow identification, and the
           transport protocols (e.g., TCP/UDP/IPsec) which can be used to
           identify 6-tuple protocol ports.
NEW
          to agree on what fields are used for flow identification.
> It seems random which ones have a period at the end. I'm sure the
> RFC Editor can help, but maybe add or remove it everywhere?
>
> Section 5.3:

All accepted, thanks!

> Some references are outdated according to idnits.

This will be picked up on the next round of publication

Please let us know if you see any additional outstanding issues.

Thanks again for the review

Lou (and co-authors)

> Regards,
> Stig
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>