Subject: [Tsv-art] Tsvart last call review of draft-ietf-detnet-ip-over-mpls-05

From: Brian Trammell via Datatracker <[email-masked]>
Date: Wed, 22 Apr 2020 04:52:47 -0700

Reviewer: Brian Trammell
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

This document presents a fairly straightforward mapping of DetNet IP flows to
DetNet over MPLS, and as such raises no concerns for transport beyond those
raised by its referent documents (draft-ietf-detnet-ip, draft-ietf-detnet-mpls,
and RFC8655); transport issues in those documents should be addressed before
this document can be published.

Note that the flow aggregation procedures in section 4.4 of
draft-ietf-detnet-ip, which are essentially included by reference in section
5.1 of this document, run counter to present and future developments in the
transport layer, specifically the deployment of multipath transports. Transport
layer protocols that split flows across multiple IP-layer N-tuples appear to
break the assumptions made about flow aggregation in these documents, and as
such it should be noted that this architecture is not apparently compatible
with multipath transport. Whether this limitation is important for DetNet's
target use cases is unclear to this reviewer, so it may have been considered by
the WG and declared out of scope.

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 27 Apr 2020 16:55:55 +0000

Hi Brian,

Thanks for your comments. Yes, transport layer is out-of-scope for DetNet scenarios.

The framework document (https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-05) says explicitly: 
 "Use of packet-by-packet distribution of the same DetNet flow over
   multiple paths is not recommended ... 
   Packet by packet load sharing, e.g., via ECMP or UCMP,
   impacts ordering and possibly jitter. "

I will add an explicit note on this here as well. So, your comment is absolutely right, multipath would impact aggregation as well. 

Many thanks
Bala'zs

-----Original Message-----
From: Brian Trammell via Datatracker <[email-masked]> 
Sent: Wednesday, April 22, 2020 1:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Tsvart last call review of draft-ietf-detnet-ip-over-mpls-05

Reviewer: Brian Trammell

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

This document presents a fairly straightforward mapping of DetNet IP flows to DetNet over MPLS, and as such raises no concerns for transport beyond those raised by its referent documents (draft-ietf-detnet-ip, draft-ietf-detnet-mpls, and RFC8655); transport issues in those documents should be addressed before this document can be published.

Note that the flow aggregation procedures in section 4.4 of draft-ietf-detnet-ip, which are essentially included by reference in section
5.1 of this document, run counter to present and future developments in the transport layer, specifically the deployment of multipath transports. Transport layer protocols that split flows across multiple IP-layer N-tuples appear to break the assumptions made about flow aggregation in these documents, and as such it should be noted that this architecture is not apparently compatible with multipath transport. Whether this limitation is important for DetNet's target use cases is unclear to this reviewer, so it may have been considered by the WG and declared out of scope.