Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-mpls-over-ip-preof-10: (with COMMENT)

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

Hi Eric,

Many thanks for your review. Reactions:

1, ## Is MPLS over UDP the only solution
As Andy wrote, the intention is to use existing standardized headers and/or encapsulations.
If OK with You we can refer the DetNet Framewok document (RFC8938) as proposed by Andy.

2, ## Section 5, IPv6 next header
Right, UDP is meant the next protocol above IPv6. IPv6 extension header(s) are not excluded.
We can fix this as follows:
OLD TEXT
   *  IPv6 next header field set to "UDP".
NEW TEXT
   *  IPv6 (last) next header field being equal to "UDP".
END

3, ## Section 1, 'correctly'
Right, I will remove the word "correctly".

Thanks
Bala'zs


----------
From: Andrew G. Malis <[e-mail]> 
Sent: Wednesday, February 21, 2024 12:37 PM
To: Éric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Éric Vyncke's No Objection on draft-ietf-detnet-mpls-over-ip-preof-10: (with COMMENT)

Eric,

Regarding your comment:

## Is MPLS over UDP the only solution ?

While using MPLS over UDP is indeed a valid solution for sequencing the
packets, I wonder whether RFC 8939 could have been updated/extended to also add
ordering, this would probably have less overhead. Was this discussed in the WG?
If so, why not adding this justification in the draft ? (note I may have missed
something obvious :-O )

Just my 2 cents as a co-author. 

One of the goals of the WG was to reuse existing IETF technology as much as possible. This is documented in RFC 8938:

3.1.1.  Data Plane Technology

   The DetNet data plane is provided by the DetNet service and
   forwarding sub-layers.  The DetNet service sub-layer generally
   provides its functions for the DetNet application flows by using or
   applying existing standardized headers and/or encapsulations.  

Given that, it was very straightforward to take advantage of RFCs 7510 and 8964. While we perhaps could have saved a few bytes in the header by rolling our own solution, reusing RFCs 7510 and 8964 simplifies both the specification and implementation, and follows the design goal in RFC 8938. Plus this technology isn't intended for environments (such as low-power or very slow networks) where a few bytes in the header would make much of a difference.

Perhaps adding a reference to that section of 8938 would satisfy your comment.

Cheers,
Andy


-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: Wednesday, February 21, 2024 9:09 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's No Objection on draft-ietf-detnet-mpls-over-ip-preof-10: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-mpls-over-ip-preof-10: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-ip-preof/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-detnet-mpls-over-ip-preof-10

Thank you for the work put into this document. I always find DetNet work
interesting and useful.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Lou Berger for the shepherd's detailed write-up including the
WG consensus and the justification of the intended status (the latter could
have been more detailed tough).

Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-detnet-mpls-over-ip-preof-09-intdir-telechat-jinmei-2024-02-15/
(thanks to Balázs for his reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Is MPLS over UDP the only solution ?

While using MPLS over UDP is indeed a valid solution for sequencing the
packets, I wonder whether RFC 8939 could have been updated/extended to also add
ordering, this would probably have less overhead. Was this discussed in the WG?
If so, why not adding this justification in the draft ? (note I may have missed
something obvious :-O )

## Section 5

`IPv6 next header field set to "UDP"` seems to ignore the optional extension
headers between the IPv6 header and the UDP header.

The wording in `IPv6 next header field set to "UDP"` seems to indicate an
action "to set" rather than "being equal to" (as suggested by the leading `The
information needed to identify individual`). Suggest to clarify.

I am most probably missing something obvious here but does this section assumes
that the only DetNet flows are UDP ?

# NITS (non-blocking / cosmetic)

## Section 1

Unsure whether 'correctly' is sensible in `correctly represented as PREOF`.

Unsure whether the reference to a YANG model is useful in the same 1st
paragraph.