Skip to main content

Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP


(Deborah Brungard)

No Objection

Alvaro Retana
(Alissa Cooper)
(Barry Leiba)
(Martin Vigoureux)

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana
No Objection
Erik Kline
No Objection
Comment (2020-11-24 for -07)
[[ questions ]]

[ section 5 ]

* Should the IPv6 flow label be included in this information summary?
  7510 and ietf-detnet-ip both discuss using the flow label when the
  outer header is IPv6...
Martin Duke
No Objection
Comment (2020-11-30 for -07)
Please address the tsvart review comment about NATs.

The sentence in the abstract that begins "The approach is..." is garbled.
Murray Kucherawy
No Objection
Comment (2020-11-30 for -07)
In Section 1, I believe "queuing" should be "queueing".

In Section 6, the sentence beginning "Notably" isn't a sentence.  I suggest:


   Notably [RFC7510], as this document
   is primarily an application of MPLS-in-UDP.


   Of particular note is [RFC7510], as this document
   is primarily an application of MPLS-in-UDP.
Robert Wilton
No Objection
Comment (2020-12-01 for -07)
I would like to thank the authors for this easy to read and understand document, and also thank Dan for his OPSDIR review.

Related to Dan's question on the manageability section, as a non blocking comment, I wonder whether it would be helpful to have informational references to either the Detnet YANG model or the Detnet OAM documents?  This might be helpful to future readers when they are relating the suite of Detnet documents together.  However, I appreciate that this would create forward references to those documents and will leave it to the discretion of the authors (and responsible AD) to decide whether such references would be helpful here.  It would also be worth noting that adding such references may also create an inconsistency with the other Detnet documents currently in the RFC editor queue unless they also have similar references added.

Roman Danyliw
No Objection
Comment (2020-11-30 for -07)
Thank you to Stephen Farrell for conducting the SECDIR review.
Warren Kumari
No Objection
Comment (2020-12-02 for -07)
Thank you to Dan for the OpsDir comments; they were helpful while performing my review
Éric Vyncke
No Objection
Comment (2020-11-27 for -07)
Thank you for the work put into this document.

I have the same question as Erik Kline + a minor nit draft-ietf-6man-segment-routing-header-26 is not RFC 8754 

Deborah Brungard Former IESG member
Yes (for -07)

Alissa Cooper Former IESG member
No Objection
No Objection (for -07)

Barry Leiba Former IESG member
No Objection
No Objection (for -07)

Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-12-01 for -07)
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

(nitty nit) these two are in the reverse order as they appear in

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.)
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2020-12-15)
Thanks for addressing my issue.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07)