Change:
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

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