Change:
IESG review comments resolved in this version
MPLSoUDP
MPLSoUDP: all 01-27 changes done.
can be merged once comments integrater, per Jan 27th meeting

Discussion:
These requirements are satisfied by the DetNet over MPLS Encapsulation described in I-D.ietf-detnet-mpls and they are partly <del> satisfied by the DetNet IP data plane defined in I-D.ietf-detnet-ip </del> <ins> satisfied (i.e., IP flows can be identified however no DetNet sequence number is carried) by the DetNet IP data plane defined in I- D.ietf-detnet-ip </ins> 2.

Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header. <del> S-Labels, d-CW and zero or more F-Labels are used as defined in I- D.ietf-detnet-mpls and are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it too is not modified. </del> <ins> S-Labels, A-Labels (when present), d-CW and zero or more F-Labels are used as defined in I-D.ietf-detnet-mpls and are not modified by this document. </ins> 4.

member flows, and each member flow will require the provisioning of their own UDP and IP header information.  The headers for each outgoing packet MUST be formatted according to the configuration <del> information and as defined in RFC7510, with one exception.  Note that the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handed as a DetNet IP packet, per I- D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support receive processing an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf- detnet-mpls, including PEF and POF, can then take place. </del> <ins> information and as defined in RFC7510, and the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handled as a DetNet IP packet, per I-D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support the receive processing defined in this document, an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf-detnet-mpls, including PEF and POF, can then take place. </ins> 5. The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: <del> Label information (S-label or F-label) to be mapped to UDP/IP flow.  Note that a single S-Label can map to multiple sets of UPD/ IP information when PREOF is used. </del> <ins> 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 to multiple sets of UDP/IP information when PREOF is used. </ins> IPv4 or IPv6 source address field. IPv4 or IPv6 destination address field. <del> IPv4 Type of Service or IPv6 Traffic Class Fields. </del> <ins> DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class Fields. </ins> UDP Source Port. UDP Destination Port. This information MUST be provisioned per DetNet flow via <del> configuration, e.g., via the controller or management plane. </del> <ins> configuration, e.g., via the controller RFC8655 or management plane. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific <del> resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </del> <ins> resources needed to provide the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </ins> individual flows. 6.