Last Call Review of draft-ietf-detnet-ip-04
review-ietf-detnet-ip-04-rtgdir-lc-venaas-2019-12-21-00

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