Skip to main content

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
Draft 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
Review review-ietf-detnet-data-plane-framework-03-rtgdir-lc-vainshtein-2019-12-26
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.
___________________________________________________________________________