Re: [Detnet] Alvaro Retana's No Objection on draft-ietf-detnet-mpls-11: (with COMMENT)

[Balázs Varga A <[e-mail]>]

Hi Alvaro,



Thanks for the detailed review. My comments are below inline.



Thanks & Cheers

Bala'zs



-----Original Message-----
From: Alvaro Retana via Datatracker <[e-mail]>
Sent: Tuesday, September 8, 2020 11:49 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Ethan Grossman <[e-mail]>
Subject: Alvaro Retana's No Objection on draft-ietf-detnet-mpls-11: (with COMMENT)



Alvaro Retana has entered the following ballot position for

draft-ietf-detnet-mpls-11: No Objection



When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



(0) I support Magnus' DISCUSS.  [I also have some comments about

§4.2.2.2/§4.2.2.3 below.]



<Bala'zs> OK. Sizing the buffer of PEF and POF is the result of end-to-end DetNet design for a given flow.

The design process is out-of-scope in this draft. Both §4.2.2.2/§4.2.2.3 below has a note in the last paragraph

what supports the sizing of the buffer ("maximum number of sequence numbers that are tracked" and

"maximum number of out of order packets that can be processed"). Furthermore the flow-information-model

(https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-10) and the YANG draft defines the

flow related parameters (MaxPayloadSize). Via these parameters buffer size is defined.





(1) §4.6.2: "DetNet provides zero congestion loss and bounded latency and jitter"



This phrase is a variation of the general statement in the Introduction:

"DetNet provides these flows with extremely low packet loss rates and assured maximum end-to-end delivery latency."  Specific to this document, how does DetNet guarantee this behavior while operating on an MPLS network?



I see that §4.5/rfc8655 focuses a series of examples on TSN (which is not required by the architecture, right?), and this document mentions other technology as examples. Still, there is no explicit indication of how the "zero congestion loss and bounded latency and jitter" can be achieved.  Instead, the use of these mechanisms is left to the implementation/operator without any guidance.  I think that not offering any guidance is a significant gap in a Standards Track document.



Most of the mechanisms mentioned as examples in §4.6.2 are "old", for example, RSVP-TE.  Pretty much the same mechanisms are listed in §4.2.3.2 when talking about the option of using DetNEt unaware nodes to deliver the same "service

parameters":



   When the DetNet service parameters of the DetNet flow or flows carried in

   an LSP represented by an F-Label can be met by an existing TE mechanism,

   the forwarding sub-layer processing node MAY be a DetNet unaware, i.e.,

   standard, MPLS LSR.  Such TE LSPs may provide LSP forwarding service as

   defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], [RFC3473],

   [RFC4875], [RFC5440], and [RFC8306].



How does DetNet guarantee "zero congestion loss and bounded latency and jitter"

while operating on an MPLS network?  The more I read, the more it seems to me that the examples provided support the concept that the same results can be obtained in an MPLS network without DetNet.



[I am out of my depth and feel like I'm probably missing something, which is why I am not balloting DISCUSS on this point.  However, I believe that the issue of specific guidance remains.]



<Bala'zs> DetNet was designed to reuse as much as possible from existing mechanisms.

For example, PREOF is a tool that does not exists in legacy MPLS networks. We have a dedicated

draft dealing with bounded latency. This document focuses on the data plane and does not intend

to cover all the end-to-end design aspects. RFC8655 and draft-ietf-detnet-data-plane-framework

intends to provide a more complete picture.



(2) Figure 4 shows the encapsulation of a DetNet App-Flow, which includes several labels + CW...  Figure 6 shows an even bigger stack (also with several F-Labels and the new A-Label, S-Label, CWs...).



What are the considerations related to the nodes' ability to support the label stack needed for DetNet operation and aggregation?  What is the relationship between the maximum number of labels supported in the network and the ability to push the required label stack onto the packet?  [Take a look at rfc8491 for a sample definition related to the Max SID Depth (MSD).]



<Bala'zs> Right. DetNet defines a single service label (S-Label) what is similar to existing PW and

VPN services. Aggregation is usually used within the network pushing an additional label.

Plus DetNet may use the TE capabilities provided by the network. So, there are no extra

requirements.



(3) §4.2.1



   A 0 bit sequence number field length indicates that there is no

   DetNet sequence number used for the flow.  When the length is zero,

   the sequence number field MUST be set to zero (0) on all packets sent

   for the flow.



   ...and ignored by the receiver??



There are several other "MUST be set to zero" phrases in the text.



<Bala'zs> Right. Receivers (sub-layer aware nodes) are configured with service specifics

(see §5.1) and process the packets accordingly.



(4) §4.2.2



   An S-Label will normally be at the bottom of the label stack once the

   last F-Label is removed, immediately preceding the d-CW.  To support

   service sub-layer level OAM, an OAM Associated Channel Header (ACH)

   [RFC4385] together with a Generic Associated Channel Label (GAL)

   [RFC5586] MAY be used in place of a d-CW.



§4.2.1 says that the d-CW "MUST be present in all DetNet packets containing app-flow data".  What are the cases when the d-CW may be substituted by the ACH/GAL combination?  The PEF/POF functions are specified in terms of the d-CW

-- is that functionality lost if the ACH/GAL are used instead?



<Bala'zs> Right, this is a topic under discussion. We have a dedicated document

dealing with OAM for DetNet MPLS. https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/

Current OAM capabilities are limited.



(5) §4.2.2



   "...zero or more F-Labels and optionally, the incoming interface,

   proceeding the S-Label MUST be used together with the S-Label to

   uniquely identify the DetNet service associated with a received

   packet.  The incoming interface MAY also be used together with any

   present F-Label(s) and the S-Label to uniquely identify an incoming

   DetNet service..."



These two phrases seem to say the same thing, but with different normative expectations.



<Bala'zs> Right, I will fix this.



(6) §4.2.2.2:



The interoperable action is not "MUST check", or "MUST ensure", but "MUST discard".



OLD>

   After a DetNet service is identified for a received DetNet MPLS

   packet, as described above, an implementation MUST check if PEF is

   configured for that DetNet service.  When configured, the

   implementation MUST track the sequence number contained in received

   d-CWs and MUST ensure that duplicate (replicated) instances of a

   particular sequence number are discarded.



NEW>

   After a DetNet service is identified for a received DetNet MPLS packet,

   as described above, if PEF is configured for that DetNet service,

   duplicate (replicated) instances of a particular sequence number MUST be

   discarded.


<Bala'zs> Thanks, I will fix this.



(7) §4.2.2.2:



"MAY wish" is not an action that can be enforced



OLD>

   Note that an implementation MAY wish to constrain the maximum number

   of sequence numbers that are tracked, on platform-wide or per flow

   basis.  Some implementations MAY support the provisioning of the

   maximum number of sequence numbers that are tracked on either a

   platform-wide or per flow basis.



NEW>

   An implementation MAY constrain the maximum number of sequence numbers

   that are tracked on either a platform-wide or per flow basis.



<Bala'zs> Thanks, I will fix this.



(8) §4.2.2.3:



The interoperable action is not "MUST check", or "MUST ensure", but "MUST process in order".



OLD>

   After a DetNet service is identified for a received DetNet MPLS

   packet, as described above, an implementation MUST check if POF is

   configured for that DetNet service.  When configured, the

   implementation MUST track the sequence number contained in received

   d-CWs and MUST ensure that packets are processed in the order

   indicated in the received d-CW sequence number field, which may not

   be in the order the packets are received.



NEW>

   After a DetNet service is identified for a received DetNet MPLS packet,

   as described above, if POF is configured for that DetNet service, packets

   MUST be processed in the order indicated in the received d-CW sequence

   number field, which may not be in the order the packets are received.



<Bala'zs> Thanks, I will fix this.



(9) §4.2.2.3:



"MAY wish" is not an action that can be enforced



OLD>

   Note that an implementation MAY wish to constrain the maximum number

   of out of order packets that can be processed, on platform-wide or

   per flow basis.  Some implementations MAY support the provisioning of

   this number on either a platform-wide or per flow basis.  The number

   of out of order packets that can be processed also impacts the

   latency of a flow.



NEW>

   An implementation MAY constrain the maximum number of out of order

   packets that can be processed, on either a platform-wide or per flow

   basis.  The number of out of order packets that can be processed also

   impacts the latency of a flow.



<Bala'zs> Thanks, I will fix this.



(10) [nits]



s/MAY required/MAY require



s/otherwise received/otherwise receive



s/a service parameters that dictates/service parameters that dictate



s/that maybe used/that may be used



<Bala'zs> Thanks, I will fix this.