[Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-over-udp-ip-07: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-mpls-over-udp-ip-07: 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-over-udp-ip/



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

Basically just nits here; as the shepherd writeup notes, it's "pretty
much just putting the pieces together".

Section 1

   2.  A method for carrying the DetNet sequence number.

   3.  A method for distinguishing DetNet OAM packets from DetNet data
       packets.

(nitty nit) these two are in the reverse order as they appear in
draft-ietf-detnet-mpls

Section 3

                                                    The UDP and IP
   header information is used to identify DetNet flows, including member
   flows, per [I-D.ietf-detnet-ip].  [...]

I couldn't find where draft-ietf-detnet-ip discussed member flows; could
you give me a pointer?

Section 4

   To support outgoing DetNet MPLS over UDP encapsulation, an
   implementation MUST support the provisioning of UDP and IP header
   information in addition or in place of F-Label(s).  Note, when PRF is

nit: s/in addition/in addition to/

Section 5

   o  Label information (A-labels, S-labels and F-labels) to be mapped
      to UDP/IP flow.  Note that for example, a single S-Label can map

nit: s/flow/flows/ (singular/plural mismatch between "labels" and "flow")

Section 6

The only potentially new consideration to the mpls-over-udp formulation
of detnet is that the forwarding logic can be split across two places
(IP+UDP headers and MPLS label stack), which makes implementation
somewhat more complext and thus prone to error.  But that's probably
more of an implementation issue than a protocol issue, so I don't feel
very strongly that it must be documented here.

That said, I would also not be opposed to repeating the (still somewhat
evolving, I guess) boilerplate from the other detnet RFCs/drafts about
"security aspects which are unique to DetNet".  The reasoning is that we
have a default Internet threat model, espoused in RFC 3552, and anything
detnet fundamentally has to consider a weaker threat model in order to
be able to do anything useful.  Since this document, in addition to the
referenced ones, is also deviating from the default Internet threat
model, that can be worth noting explicitly.

   [RFC8655] and [I-D.ietf-detnet-security].  Finally,MPLS and IP

nit: space after comma.

Section 10.2

(draft-ietf-6man-segment-routing-header is RFC 8754, now, though I'm
sure the RFC Editor will catch that.)