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

["Don Fedyk" <[e-mail]>]

Hi Sasha

 

Sorry, now I had some travel.  I’m attaching the pdf of the diff (since
html I attached failed).  (The PDF seems to lose the color highlighting).  I
attached the modified file and you can do your own diff. 

Note that my comments are still of the Jan 13th date.  I will address your
points where noted below.  And then provide an updated draft and diff.

So you may want to wait for the update. 

 

Comments/clarifications below. [Don]

Also I have snipped out agreed sections for brevity.  

 

Thanks,

Don 

 

From: detnet <[e-mail]> On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 21, 2020 6:42 AM
To: Don Fedyk <[e-mail]>
Cc: [e-mail]; 'Yemin (Amy)' <[e-mail]>;
[e-mail]; 'Balázs Varga A' <[e-mail]>;
[e-mail]; [e-mail]
Subject: Re: [Detnet] [RTG-DIR] RTG-DIR last call review of
draft-ietf-detnet-data-plane-framework-03

 

Don,

First of all, apologies for a much delayed response.

[Don] No worries

 

Unfortunately I could not open the diff you've sent. 

If you can re-send it in some commonly readable other format, it would be
great (HTML or even PDF would definitely be the best).

Otherwise please send the new version of the draft as plain text.

 

Meanwhile please see some preliminary comments to your answers inline
below.

It seems that most issues I’ve raised in my review have been successfully
resolved.

 

Regards, and, again, apologies for the delay,

Sasha

 

Office: [phone]

Cell:      [phone]

Email:   [e-mail]
<mailto:[e-mail]> 

 

<snip>

 

[Don] Two authors are now contributors. [[Sasha]] As I have said, this is
between the team of the authors/contributors and the ADs, I am OK with the
proposed resolution.

[Don] Agreed

 

<snip>

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:

 

[Don] Ordering is at the server [[Sasha]] Did you mean “Service” here?
sub-layer. Resources - buffers for

reordering are at this layer. Updated

[Don] Yes Service Updated text delineates where buffer resources are used.
Section 1., paragraph 5:

 

OLD:

 

 

 

    DetNet flows may be carried over network technologies that can

 

    provide the DetNet required service characteristics.  For example,

 

    DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive

 

    Network (TSN) [IEEE802.1TSNTG] sub-networks.  However, IEEE 802.1 TSN

 

    support is not required and some of the DetNet benefits can be gained

 

    by running over a data link layer that has not been specifically

 

    enhanced to support TSN.

 

 

 

NEW:

 

 

 

    DetNet flows may be carried over network technologies that can

 

   provide the DetNet required service characteristics.  For example,

 

    DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive

 

    Network (TSN) [IEEE802.1TSNTG] sub-networks.  However, IEEE 802.1 TSN

 

    support is not required in DetNet.  TSN frame preemption is an

 

    example of a forwarding layer capability that is typically not

 

    replicated in other forwarding technologies.  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.

 

[[Sasha]]  The change above seems to address my other question (impact of
non-support of TSN frame pre-emption inn other forwarding technologies.

[[Sasha]] I still wonder however, whether “typically not” is strong enough,
or we can state that frame pre-emption is a unique capability of TSN?

[Don] Well I am aware of other technologies that used preemption and
internet search say  RFC2686 and RFC2687 is one example.  The wording was
intentional on my part. 

Also we do not want to preclude other data planes that may have the
capability.   

                              

 

Section 4.2.3., paragraph 1:

 

OLD:

 

 

 

    As discussed in Section 1, this document does not specify the

 

    mechanisms needed to eliminate packet contention, packet loss or

 

    reduce jitter for DetNet flows at the DetNet forwarding sub-layer.

 

    The ability to manage node and link resources to be able to provide

 

    these functions is a necessary part of the DetNet controller plane.

 

    It is also necessary to be able to control the required queuing

 

    mechanisms used to provide these functions along a flow's path

 

    through the network.  See [I-D.ietf-detnet-ip] and Section 4.1 for

 

    further discussion of these requirements.

 

 

 

NEW:

 

 

 

    As discussed in Section 1, this document does not specify the

 

    mechanisms needed to eliminate packet contention, packet loss or

 

    reduce jitter for DetNet flows at the DetNet forwarding sub-layer.

 

    The ability to manage node and link resources to be able to provide

 

    these functions is a necessary part of the DetNet controller plane.

 

   [[Sasha]]  The new text seems to begin here.

  
    It is also necessary to be able to control the required queuing

 

    mechanisms used to provide these functions along a flow's path

 

    through the network.  See [I-D.ietf-detnet-ip] [[Sasha]] Can you please
provide a reference to the specific text in this draft? and Section 4.1 for

[Don] Will add a section reference.

 

    further discussion of these requirements.  Some forms of protection

 

    may enforce packet loss or change jitter characteristics in the cases

 

    where packets are reordered when out-of-order packets are received at

 

    the service sub-layer.

 

                                                  i.     Section 4.2 of RFC

4385

<https://clicktime.symantec.com/33EPoJPGK3P16uEhFVxEQPF6H2?u=https%3A%2F%2F
t

ools.ietf.org%2Fhtml%2Frfc4385>  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://clicktime.symantec.com/37VT1KAX7zdhNmeuVcyLo5c6H2?u=https%3A%2F%2F
t

ools.ietf.org%2Fhtml%2Frfc4179>  (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.

 

[Don] add a text to clarify. (also above change).

 

Section 3., paragraph 7:

 

OLD:

 

 

 

    The service sub-layer provides additional support beyond the

 

    connectivity function of the forwarding sub-layer.  An example of

 

    this is Packet Replication, Elimination, and Ordering functions see

 

    Section 4.3.

 

 

 

NEW:

 

 

 

    The service sub-layer provides additional support beyond the

 

    connectivity function of the forwarding sub-layer.  An example of

 

    this is Packet Replication, Elimination, and Ordering functions see

 

    Section 4.3.  The ordering (POF) uses sequence numbers added to

 

    Packets

[[Sasha]] Are sequence numbers always added to packets in DetNet?

[Don] Nope

Quoting from the  <https://tools.ietf.org/html/draft-ietf-detnet-ip-04>
detnet-ip draft, section 4.2:

 

   As noted earlier, service protection must be implemented within each

   link / sub-network independently, using the domain specific

   mechanisms.  This is due to the lack of unified end-to-end sequencing

   information that could be used by the intermediate nodes.

This suggests to me that DetNet over IP data plane does not add any
sequence numbers to the packets.

[Don] DetNet over IP does not add a sequence number but the DetNet
architecture states that sequence numbers at higher Layers may be utilized
for example IPsec.    

And the  <https://tools.ietf.org/html/draft-ietf-detnet-mpls-04>
detnet--mpls draft in Section 4.2.1 includes the sequence number space of 0
(zero) bits as MUST to support (along with 16 bits and 28 bits space),
effectively making it possible not to add a meaningful sequence number.

[Don] Will look to see if there is something I can clarify but if you have
specific text please point it out. 

 

 

  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.

 

    Reordering requires buffer resources and has impact on the delay and

 

    jitter of packets in the DetNet flow.

 

<snip>

 

5.            The draft states, in Section 4.2.4., that “DetNet
applications

typically generate bidirectional traffic”.  

 

1.            I have looked up RFC 8557

<https://clicktime.symantec.com/3S5RkymWb9AHCmyh98pDnNf6H2?u=https%3A%2F%2F
t

ools.ietf.org%2Fhtml%2Frfc8557>  and, especially, RFC 8578

<https://clicktime.symantec.com/32QD67HM2j2fhREf17yZBwp6H2?u=https%3A%2F%2F
t

ools.ietf.org%2Fhtml%2Frfc8578> , 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. 

2.            I think that some clarification, preferably with references
to

specific DetNet use cases that require bidirectional traffic, would be

useful

 

[Don] 

 

Section 4.2.4., paragraph 1:

 

OLD:

 

 

 

    DetNet applications typically generate bidirectional traffic.  IP and

 

    MPLS typically treat each direction separately and do not force

 

    interdependence of each direction.  MPLS has considered bidirectional

 

    traffic requirements and the MPLS definitions from [RFC5654] are

 

    useful to illustrate terms such as associated bidirectional flows and

 

    co-routed bidirectional flows.  MPLS defines a point-to-point

 

    associated bidirectional LSP as consisting of two unidirectional

 

    point-to-point LSPs, one from A to B and the other from B to A, which

 

    are regarded as providing a single logical bidirectional forwarding

 

    path.  This is analogous to standard IP routing.  MPLS defines a

 

    point-to-point co-routed bidirectional LSP as an associated

 

    bidirectional LSP which satisfies the additional constraint that its

 

    two unidirectional component LSPs follow the same path (in terms of

 

    both nodes and links) in both directions.  An important property of

 

    co-routed bidirectional LSPs is that their unidirectional component

 

    LSPs share fate.  In both types of bidirectional LSPs, resource

 

    reservations may differ in each direction.  The concepts of

 

    associated bidirectional flows and co-routed bidirectional flows can

 

    also be applied to DetNet IP flows.

 

 

 

NEW:

 

 

 

    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.  IP and MPLS typically treat each direction separately

 

   and do not force interdependence of each direction.  MPLS has

 

    considered bidirectional traffic requirements and the MPLS

 

    definitions from [RFC5654] are useful to illustrate terms such as

 

    associated bidirectional flows and co-routed bidirectional flows.

 

    MPLS defines a point-to-point associated bidirectional LSP as

 

    consisting of two unidirectional point-to-point LSPs, one from A to B

 

    and the other from B to A, which are regarded as providing a single

 

    logical bidirectional forwarding path.  This is analogous to standard

 

    IP routing.  MPLS defines a point-to-point co-routed bidirectional

 

    LSP as an associated bidirectional LSP which satisfies the additional

 

    constraint that its two unidirectional component LSPs follow the same

 

    path (in terms of both nodes and links) in both directions.  An

 

    important property of co-routed bidirectional LSPs is that their

 

    unidirectional component LSPs share fate.  In both types of

 

    bidirectional LSPs, resource reservations may differ in each

 

    direction.  The concepts of associated bidirectional flows and co-

 

    routed bidirectional flows can also be applied to DetNet IP flows.

[[Sasha]] After re-reading 4.2.4 I understand that the most relevant part
of it is para 3 (beginning with the words “DetNet's use of PREOF”.
With this understanding in mind the new text looks stuffiest. 
[Don] stuffiest = to suffice?  Stuffiest makes me chuckle though. 😊

 

<snip>