Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS
draft-ietf-detnet-tsn-vpn-over-mpls-07

[[ comments ]]

* I know that RFC 8964 doesn't have any text about MTU and fragmentation
  considerations, but RFC 3985 does.

  The layering diagram in section 4.2 made me thing it might be worth
  either adding some text or pointing to some text elsewhere that
  advises the DetNet network operator to make sure that all the DetNet
  encapsulation overhead plus the MTU of the TSN not exceed the DetNet
  network's MTU, otherwise fragmentation considerations arise.

  Even a reference to RFC 3985 section 5.3 might be enough to remind the
  reader of these additional considerations.

In Section 2.2, you define "CW", but the term used in the document is actually "d-CW".  "MPLS-TP", though defined here as well, is not present elsewhere in the document.

Thank you to Magnus Nystrom for the SECDIR review.  There are a few nits in that review that should be addressed.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Mainly out of curiosity, why is draft-ietf-detnet-tsn-vpn-over-mpls standard track while draft-ietf-detnet-mpls-over-tsn is informational ? (and I understand that they are dual protocols TSNoMPLS vs. MPLSoTSN)

-- Abstract --
Please expand TSN as it is not a RFC Editor well-known acronym.

The following references should be Normative: I-D.ietf-detnet-security, IEEE8021CB, IEEE8021Q, IEEEP8021CBdb, RFC8655 and RFC8938.

Some of these references describe TSN, an understanding which is required to execute normative actions.  Others represent the architecture, framework, and security considerations for DetNet -- note that other data plane documents use them normatively as well.

While I could easily imagine a document like this being an Informational
document, I don't object to the requested Proposed Standard status.
(FWIW, the only strong new normative requirement I remember seeing is
that aggregation of TSN flows into DetNet flows "SHALL be supported".)

I didn't take the time to sign up for an IEEE account to use the "IEEE Get"
program and pull the external references, but what is described from them
seems to make sense just from the standalone descriptions here.

I just have a couple of (barely) substantive comments, followed by some
editorial/nit-level remarks that need no reply.

Section 7

Given that this documents calls for flooding of TSN frames in some
scenarios, it seems like a caution against the risk of L2 loops would
not be out of place (though I would hope no one would be surprised about
it).

Section 10.2

I think the IEEE references need to be normative; we say that DetNet
Edge Node acts as a TSN entity and so compliance with the TSN specs is
mandatory.

And the editorial stuff:

Section 4.1

                                                        MPLS DetNet
   nodes and transit nodes include DetNet forwarding sub-layer
   functions, support for notably explicit routes, and resources
   allocation to eliminate (or reduce) congestion loss and jitter.

nits: I think this is better as "notably, support for explicit routes
and resource allocation to eliminate (or reduce) congestion loss and
jitter".

Section 4.2

My understanding is that each column in figure 3 is intended to
represent a distinct TSN Stream/App-flow; it might be useful to confirm
that somewhere (e.g., with a note about showing three example flows in
the figure).

   In the figure, "Application" indicates the application payload
   carried by the TSN network.  "MPLS App-Flow" indicates that the TSN
   Stream is the payload from the perspective of the DetNet MPLS data
   plane defined in [RFC8964].  [...]

nit: the figure seems to say "App-Flow for MPLS" rather than the "MPLS
App-Flow" in the quoted prose.

Section 5

   Description of Edge Nodes procedures and functions for TSN over
   DetNet MPLS scenario follows the concept of [RFC3985] and covers the
   Edge Nodes components shown on Figure 1.  In this section the
   following procedures of DetNet Edge Nodes are described:

some nits here; maybe
NEW:
> The description of Edge Node procedures and functions for TSN over
> DetNet MPLS scenarios follows the concepts from [RFC3985], and covers
> the Edge Node components shown in Figure 1.  In this section the
> following procedures of DetNet Edge Nodes are described:

Section 5.1

   TSN specific functions are executed on the data received by the
   DetNet Edge Node from the connected CE before forwarded to connected
   CE(s) or presentation to the DetNet Service Proxy function for
   transmission across the DetNet domain.  [...]

nit: there's a type of speech mismatch between "forwarded" and
"presentation" (and "forwarded" would need to be "being forwarded" in
order to be grammatical), so the list doesn't have a parallel structure.
I'd suggest "before being forwarded to connected CE(s) or presented to
the DetNet Service Proxy function", but there are plenty of other valid
options.

   When a TSN entity of the PE receives a packet from the DetNet Service
   Proxy, it first checks via Stream Identification (see Clause 6. of
   IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
   whether the packet belongs to a configured TSN Stream.  If no Stream
   ID is matched, then packet is dropped.  [...]

nit: s/then packet/then the packet/

Section 5.2

   When a DetNet Service Proxy receives a packet from the TSN Entity it
   MUST check whether such an App-flow is present in its mapping table.
   If present it associates the internal DetNet flow-ID to the packet
   and MUST forward it to the DetNet Service and Forwarding sub-layers.
   If no matching statement is present it MUST drop the packet.

(nit) this seems to be the only place I could find that uses the term
"statement" to refer to an entry in the DetNet flow mapping table; I'd
suggest using a phrasing like "if no match is found".

               The management or control function that provisions flow
   mapping SHALL ensure that adequate resources are allocated and
   configured to provide proper service requirements of the mapped
   flows.

nit: I think we'd say "provider proper service that meets the
requirements" or "to fulfil the service requirements"; just "providing
service requirements" doesn't seem to match up to the intended meaning.

   Due to the (intentional) similarities of the DetNet PREOF and TSN
   FRER functions service protection function interworking is possible
   between the TSN and the DetNet domains.  Such service protection
   interworking scenarios MAY require to copy sequence number fields
   from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking
   is out-of-scope in this document and left for further study.

This feels more like a descriptive "may" or "might" than a normative
"MAY" to me.

Section 5.3

   sequence number are not valid outside the DetNet network.  MPLS
   (DetNet) Edge node terminates all related information elements
   encoded in the MPLS labels.

nit: missing article for "MPLS Edge node", but I'd suggest converting to
the plural "Edge nodes terminate" to avoid the issue.

Section 6

                         For example, it may be not trivial to locate
   the egress point/interface of a TSN Streams with a multicast
   destination MAC address.  

nit: singular/plural mismatch "a TSN Streams" (it looks like using the
singular "Stream" is the minimal change to resolve).