Original text:
are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it is not modified as well. <del> To support outgoing DetNet MPLS over IP, an implementation MUST support the provisioning of IP/UDP header information in place of sets of F-Labels.  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet flows and therefore, when PRF is supported, multiple IP/UDP headers MAY be provisioned. When multiple IP/UDP headers are provisioned for a particular </del>  outgoing DetNet IP flow, a copy of the outgoing packet, including the <del> pushed S-Label, MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. </del>  To support receive processing an implementation MUST also support the <del> provisioning of received IP/UDP header information.  When S-Labels are taken from platform label space, all that is required is to provision that receiving IP/UDP encapsulated DetNet MPLS packets is permitted.  Once the IP/UDP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, IP/UDP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app- flows based on the combination of S-Label and incoming IP/UDP header. Normal receive processing, including PEOF can then take place. </del>  <del> 4. </del>  The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP

Reviewer comments:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

Revised text:
are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it is not modified as well.  <ins> 4. To support outgoing DetNet MPLS over UDP/IP, an implementation MUST support the provisioning of UDP/IP header information in addition or in place of sets of F-Label(s).  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet MPLS flows and therefore, when PRF is supported, multiple UDP/IP headers MAY be provisioned. [Note: PRF is an MPLS function.  It produces member flows.  Member flows have 1to1 mapping to UDP/IP headers.  So why are multiple headers provisioned?  Delete next sentence?] When multiple UDP/IP headers are provisioned for a particular </ins> outgoing DetNet IP flow, a copy of the outgoing packet, including the  <ins> pushed S-Label (and optional F-label(s)), MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. [Note: What about IPv4 Type of Service and IPv6 Traffic Class Fields? Do we intend to set them?] </ins> To support receive processing an implementation MUST also support the  <ins> provisioning of received UDP/IP header information. </ins>  <ins> [Note: Are the receiving nodes T-PE nodes?  Why?] When S-Labels are taken from platform label space, all that is required is to provision that receiving UDP/IP encapsulated DetNet MPLS packets is permitted.  Once the UDP/IP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, UDP/IP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app-flows based on the combination of S-Label and incoming IP/UDP header.  Normal receive processing, including PEOF can then take place. 5. The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows: IPv4 and IPv6 source address field. IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored. IPv4 and IPv6 destination address field. IPv4 and IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored. IPv4 protocol field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv6 next header field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv4 Type of Service and IPv6 Traffic Class Fields. IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a zero (0) effectively means that theses fields are ignored. UDP Source Port.  Exact and wildcard matching is required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. 6. </ins> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP