Re: [Detnet] RtgDir review: draft-ietf-detnet-ip-04.txt

[Balázs Varga A <[e-mail]>]

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 <[e-mail]> 
Sent: Saturday, December 21, 2019 2:33 AM
To: <[e-mail]> <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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