Last Call Review of draft-ietf-detnet-data-plane-framework-03
review-ietf-detnet-data-plane-framework-03-rtgdir-lc-vainshtein-2019-12-26-00
| Request | Review of | draft-ietf-detnet-data-plane-framework |
|---|---|---|
| Requested revision | No specific revision (document currently at 06) | |
| Type | Last Call Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2019-12-27 | |
| Requested | 2019-12-06 | |
| Requested by | Deborah Brungard | |
| Authors | Balazs Varga , János Farkas , Lou Berger , Andrew G. Malis , Stewart Bryant | |
| I-D last updated | 2019-12-26 | |
| Completed reviews |
Rtgdir Last Call review of -03
by Sasha Vainshtein
(diff)
Tsvart Last Call review of -04 by Yoshifumi Nishida (diff) Genart Last Call review of -04 by Christer Holmberg (diff) Secdir Last Call review of -04 by Chris M. Lonvick (diff) |
|
| Comments |
Prep for Last Call |
|
| Assignment | Reviewer | Sasha Vainshtein |
| State | Completed | |
| Request | Last Call review on draft-ietf-detnet-data-plane-framework by Routing Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/iycydS3pAfD01oPjc4NqQyEtcBI | |
| Reviewed revision | 03 (document currently at 06) | |
| Result | Has issues | |
| Completed | 2019-12-26 |
review-ietf-detnet-data-plane-framework-03-rtgdir-lc-vainshtein-2019-12-26-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<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: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com ___________________________________________________________________________ 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. ___________________________________________________________________________