Change:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP

Discussion:
path with the appropriate forwarding and resource allocation information. <ins> The path could be used a distributed control plane such as RFC2205 or RSVP-TE RFC3473 extended to support DetNet IP flows. </ins> The path could be implemented using IPv6-based segment routing when extended to support resource allocation.

signaling approaches) or to network controllers (for centralized approaches) <del> Scale to handle a large number of DetNet flows in a domain (which may require per-flow signaling or provisioning) </del> <ins> Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning) </ins> Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the

required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via <del> configuration and the controller plane, see m-cp-considerations. </del> <ins> configuration, e.g., via the controller plane described in m-cp- considerations. </ins> Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a

7. <del> This section defines how IP encapsulated DetNet flows are carried over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol- mpls.  The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS app perspective.  The corresponding example DetNet Sub-Network format is shown in fig_dn_ip_mpls_sn_ex. </del> <ins> This section defines how IP encapsulated flows are carried over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-mpls.  As Non-DetNet and DetNet IP packets are identical on the wire, this section is applicable to any node that supports IP over DetNet MPLS, and this section refers to both cases as DetNet IP over DetNet MPLS. 7.1. This section provides example uses of IP over DetNet MPLS for illustrative purposes. fig_dn_ip_mpls_detnet illustrates DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS network.  In this figure, Relay nodes sit at the boundary of the MPLS domain since the non-MPLS domain is DetNet aware.  This figure is very similar to the DetNet MPLS Network figure in I-D.ietf- detnet-dp-sol-mpls.  The primary difference is that the Relay nodes are at the edges of the MPLS domain and therefore function as T-PEs, and that service sub-layer functions are not provided over the DetNet IP network.  The transit node functions show above are identical to those described in I-D.ietf-detnet-dp-sol-mpls. fig_ip_pw_detnet illustrates how relay nodes can provide service protection over an MPLS domain.  In this case, CE1 and CE2 are IP DetNet end systems which are interconnected via a MPLS domain such as described in I-D.ietf-detnet-dp-sol-mpls.  Note that R1 and R3 sit at the edges of an MPLS domain and therefore are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE. fig_ip_mpls_detnet illustrates non-DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled MPLS network.  It differs from fig_dn_ip_mpls_detnet in that the hosts and edge IP networks are not DetNet aware.  In this case, edge nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary.  The edge nodes provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows.  While the node types differ, there is essentially no difference in data plane processing between relay and edges.  There are likely to be differences in controller plane operation, particularly when distributed control plane protocols are used. fig_pw_detnet2 illustrates how it is still possible to provided DetNet service protection for non-DetNet aware end systems.  This figures is basically the same as fig_ip_pw_detnet, with the exception that CE1 and CE2 are non-DetNet aware end systems and E1 and E3 are edge nodes that replace the relay nodes R1 and R3. 7.2. The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS app perspective.  The corresponding example DetNet Sub-Network format is shown in fig_dn_ip_mpls_sn_ex. </ins> In the figure, "IP App-Flow" indicates the payload carried by the DetNet IP data plane.  "IP" and "NProto" indicate the fields

procedures: the mapping of flow identifiers; and ensuring proper traffic treatment. <del> 7.1. </del> <ins> 7.3. </ins> A relay node that sends a DetNet IP flows over a DetNet MPLS network MUST map a single DetNet IP flow into a single app-flow and MUST

DetNet IP flows sent over an DetNet MPLS network.  Aggregation as defined in ip-agg MAY be used to identify an individual DetNet IP flow.  The provisioning of the mapping of DetNet IP flows to DetNet <del> MPLS app-flow information MUST be supported via configuration and the controller plane, see m-cp-considerations. </del> <ins> MPLS app-flow information MUST be supported via configuration, e.g., via the controller plane described in m-cp-considerations. </ins> A relay node MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS

DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in ip-flow-id.  An implementation MUST support the provisioning of handling of received DetNet MPLS <del> data plane as DetNet IP flows via configuration and the controller plane, see m-cp-considerations.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </del> <ins> data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </ins> <del> 7.2. </del> <ins> 7.4. </ins> The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane.  When an