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

[Alvaro Retana via Datatracker <[e-mail]>]

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.]

(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.]

(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).]

(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.

(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?

(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.

(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.

(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.

(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.

(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.

(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