Re: [Detnet] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03

[Alexander Vainshtein <[e-mail]>]

Hello,
I have reviewed the -04 version of the draft, and checked whether my RTG-DIR review comments have been resolved.
The status of my comments is presented in the table below.

Review comment
Status in the -04 version
Resolution status
Additional comments
Requested making RFRC 8655 a Normative reference
RFC8655 appears in the list of Normative references, and all occurrences of  reference to the preceding draft are replaced with the references to RFC 8655
Fully resolved

I have failed to understand whether the “Packet Ordering Function (POF)” is expected to actually reorder (or try to reorder) packets that have been received out of order, or could simply discard such packets
The following text has been added two Section 3:
The ordering (POF) uses sequence numbers added to packets enabling a range of packet order protection from simple ordering and dropping out-of-order packets to more complex reordering of a fixed number of out-of-order, minimally delayed packets.
Fully resolved

Asked to explain the relationship between differential delay of the paths used in packet replication and ability to eliminate replicated packets
Section 3.6.2.2 has been added
Fully resolved

Asked to clarify whether the DetNet data plane is expected to provide any equivalent of the frame preemption function defined in IEEE802.1Qbu
The following test is added to Section 1:
TSN frame preemption is an    example of a forwarding layer capability that is typically not   replicated in other forwarding technologies

Fully resolved

Asked to clarify what could be the impact of NOT supporting frame preemption in DetNet on its goals, especially on jitter?
The following test is added to Section 1:
Most of DetNet benefits can be gained by running over a data link layer that has not been specifically enhanced to support all TSN capabilities but for certain networks and traffic mixes delay and jitter performance may vary due   to the forwarding sub-layer intrinsic properties
Fully resolved

Expressed doubts in the statement about DetNet applications typically generating bidirectional traffic in Section 4.2.4.
The new text in Section 4.2.4 says:
In many cases DetNet flows can be considered unidirectional and   independent.  However, there are cases where the DetNet service   requires bidirectional traffic from a DetNet application service perspective.
Fully resolved

Asked to provide specific references to DetNet use cases  where bidirectional application traffic is required
Did not find any specific use cases of bidirectional behavior requirements
Not resolved
It would be nice if specific use cases listed in RFC 8578<https://tools.ietf.org/html/rfc8578> could be referenced.
But this is clearly a “nice to have” wish, not mandatory.
Asked to explain the term d-CW and to provide a suitable reference
Reference to the DetNet-MPLS draft is provided
Fully resolved

Asked to provide suitable references to the definition of the DetNet Controller Plane
References to RFC 7426 and FC 8655 are provided
Fully resolved

Asked to provide some inputs about network coding
A reference to the Charter of the NWCRG is provided
Fully resolved



I would also like to add that the following sentence in Section 3.6.1.1 looks to me as a new nit:

Misbehaving DetNet flows must be able to be detected and ensure...

I am not a native English speaker and therefore may misinterpret this sentence, but sounds to me as an attempt to impose a requirement on misbehaving DetNet flows – but I strongly doubt the flows that are already misbehaving (i.e., ignoring some requirements) would be nice enough to comply to this one. The previous version of this sentence looked better to me.

Hopefully these notes will be useful.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Alexander Vainshtein
Sent: Thursday, December 26, 2019 6:30 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Yemin (Amy) <[e-mail]>
Subject: RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03


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<https://clicktime.symantec.com/3HoggwpVJ3tAkafdde3M5kS6H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir>

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-data-plane-framework-03.txt
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 26-Dec-19
IETF LC End Date: Not known
Intended Status: Informational

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

Comments:
The draft is one of a group of DetNet documents.
One of these documents has been already published as RFC 8655<https://clicktime.symantec.com/3G9XdBmhXdcKZ9XbdXGkvRB6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8655>, while several others are in different stages of the IETF process.
These documents seem to be closely related, and this makes reading and understanding the DetNet Data Plane Framework draft complicated (at least for somebody, like me, who is not deeply immersed in the topic).
Specifically, reading RFC 8655 seems to me a mandatory prerequisite for understanding the data plane framework draft.

I would also like to notice that there are 7 authors listed on the front page of  the draft.
I defer to the WG chairs and the ADs to decide whether this is acceptable, or any changes are required.

I have privately discussed my original comments with the authors prior to posting this review, and received highly relevant feedback that has helped me to resolve some of my concerns and to clarify some of the remaining ones.  I also believe that we have reached a rough consensus regarding disposition of the majority of my comments. I would like to express my gratitude to the authors of the draft for their  responsiveness and cooperation.

Major Issues: No major issues found.

Minor Issues:

1.       As mentioned above, RFC 8655 looks to me a mandatory pre-requisite for reading and understanding this draft. Therefore I suggest making it a Normative reference (currently there is just an Informative reference to the draft that already has been published as RFC 8655). This issue has been discussed with the authors, and, as I can see it, there were no objections to such a change.

2.       After reading both  RFC 8655 and the DetNet Data Plane Framework draft I have failed to understand whether the “Packet Ordering Function (POF)” is expected to actually reorder (or try to reorder) packets that have been received out of order, or could simply discard such packets:

a.       On one hand:

                                                               i.      The DetNet Data Plane Framework draft says in Section one that “The service sub-layer is used to provide  DetNet service protection and reordering”

                                                             ii.      Section 3.2.2.2 of RFC 8655 says that “The POF uses the sequencing information to reorder a DetNet flow's  packets that are received out of order”

b.       On the other hand, neither of these documents mentions the need for additional resources (buffers and timers) that are required for reordering of packets received out of order, and impact of this operation on the packet delay variation (a.k.a. jitter). What’s more, allocation of these resources (if they are used) would have to be done at the DetNet service sub-layer, and this seems to contradict RFC 8655  where allocation of resources is associated just with the forwarding sub-layer (see Figure 2 in Section 4.1.1 of RFC 8655 that is also reproduced verbatim in the DetNet Data Plane Framework draft).

c.       For comparison, the PWE3 documents that deal with sequencing and reordering clearly differentiate between reordering and discard of packets that have been received out of order:

                                                               i.      Section 4.2 of RFC 4385<https://tools.ietf.org/html/rfc4385> provides a clear definition of PWE packets received in and  of order. It then says that “If the packet is found to be in order, it MAY be delivered  immediately” and “Packets that are received out of order MAY either be dropped or  reordered.  The choice between dropping or reordering an out-of-sequence packet is at the discretion of the receiver”.  I.e., ordering can be achieved by simply dropping packets that have been received out of order

                                                             ii.      Section 7.3.2 of RFC 4197<https://tools.ietf.org/html/rfc4179> (that deals with TDM PWs) says that  packets received out of order “SHOULD be reordered if not judged to be too late or too early for  playout”

d.       From my POV the DetNet Data Plane Framework draft should clearly define the expectations from the POF regarding handling of packets that have been received out-of-order, and the impact of reordering (if it is used) on the goals of the DetNet services.

3.       Elimination of replicated packets is yet another important function of the DetNet data plane that seems to be under-specified. From my POV ability to perform this function depends on the (worst case of the) differential delay between the paths taken through the network by the multiple copies of the packet, but I have not found any discussion of such a linkage in the draft.

4.       The DetNet Data Plane Framework draft mentions in the Introduction that  TSN as a possible (but not mandatory) underlay for carrying the DetNet flows, and says that “some of the DetNet benefits can be gained by running over a data link layer that has not been specifically enhanced to support TSN”. It would be really nice if the draft would also specify which (if any) of the DetNet goals could not be achieved if it runs over the data link layer that has not been enhanced to support TSN. Specifically, I would like to see:

a.       Whether the DetNet data plane is expected to provide any equivalent of the frame preemption function defined in IEEE802.1Qbu

                                                               i.      The relevant text in RFC 8655 only says that all the TSN techniques are currently defined for Ethernet and Layer 2 bridging, “they are all, except perhaps for packet preemption, equally applicable to media other than Ethernet and to routers as well as bridges”

                                                             ii.      Personally I believe that preemption is closely related to usage of specific media, but this may be due to my admitted ignorance in these matters

b.       What could be the impact of NOT supporting frame preemption in DetNet on its goals, especially on jitter?

5.       The draft states, in Section 4.2.4., that “DetNet applications typically generate bidirectional traffic”.

a.       I have looked up RFC 8557<https://tools.ietf.org/html/rfc8557> and, especially, RFC 8578<https://tools.ietf.org/html/rfc8578>, but did not find there any justifications for this statement. In fact, some of the application listed in RFC 8578 (e.g. all applications related to audio and video) seem to be inherently unidirectional.

b.       I think that some clarification, preferably with references to specific DetNet use cases that require bidirectional traffic, would be useful

6.       The term “d-CW” appears several times in the draft without either am explicit definition or a clear reference to such a definition.

a.       The definition of d-CW seems to be in Section 4.2.1 of the DetNet Data Plane: MPLS<https://tools.ietf.org/html/draft-ietf-detnet-mpls-04> draft

                                                               i.      If this is correct, then an explicit reference to this draft should be added IMHO

                                                             ii.      I am not sure if this would make  the DetNet Data Plane: MPLS draft a Normative reference to this draft, or it can be left as an Informative reference (as today)

b.       I find it somewhat surprising that the  term d-CW d is not used in Section 3.5. “DetNet MPLS Data Plane” of the DetNet Data Plane Framework draft. Instead, it only mentions “a shim layer called a control word (CW)” followed by a reference to RFC 4385.

7.       In Section 4 the draft describes the DetNet data plane requirements to the DetNet Controller Plane without providing any explicit definition or a reference of the latter:

a.       It seems that the relevant definition appears in Section 4.4.2 of RFC 8655

b.       IMHO adding this reference explicitly (or even reproducing it verbatim) would help the reader to understand why, say, allocation and distribution of S-labels and F-labels are required from the DetNet Controller plane in the draft

8.       Section 3.6.1.4 “Network Coding” says that “Network Coding, not to be confused with network programming, comprises several techniques where multiple data flows are encoded”.

a.       No further explanation or reference is provided

b.       I freely admit complete ignorance in all matters dealing with Network Coding, therefore I did not understand why this section appears in the draft.

c.       One of the authors has pointed to the IRTF Coding for efficient NetWork Communications<hhttps://datatracker.ietf.org/rg/nwcrg/about/> Research Group (NWCRG)  as the possible source of information about Network Coding, and this was really helpful to me. I think that adding at least this pointer (and possibly some others) as Informative Reference(s) to the draft,  would be helpful  to other readers as well.

Nits:
I did not run the nits check on the draft. So I just included two sentences that looked problematic to me. However, I am not a native English speaker, so please consider these with a grain of salt.


1.       Something seems to be wrong with the grammar in the following sentence in Section 3.6.1.1: “Misbehaving DetNet flows must be detected and it have to be ensured that they do not compromise QoS of other flows”

2.       The next sentence in the same section “The use of (queuing, policing, shaping) policies can be used to ensure that the allocation of resources reserved for DetNet is met” IMHO should be rephrased e.g., like “Queuing, policing, and shaping policies can be used to ensure that the allocation of resources reserved for DetNet is met”.

Hopefully, these notes will be useful.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________