Original text:
The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress <del> AC, and egress edge node has to know how to.. </del>  [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision <del> Time Protocol (PTP) [IEEE1588].  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </del>  forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority

Reviewer comments:
Put the text that was taken out of the payload ident section back in. Fixed some compile warnings Two were figs too large One was use of [IEEE1588] instead of Rest were apparently unused references Requesting pull so we are in sync on this.
Looks OK to me. Merging all these chnanes.

Revised text:
The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress  <ins> AC, and egress edge node has to know how to prepare the packet for transmission on the egress AC. On ingress a DetNet edge node has to classify the packets into those that are for transmission as Detnet packets and those that are for transmission as "normal" packets at one of more lower priorities. The packet type is indicated to the egress edge node through the value of the S-label.  Thus, when the egress edge node looks up the S-label one of the parameters returned is the packet type which in turn tells the egress edge node how to prepare the packet for transmission over the egress AC. The consequence of this approach is that if multiple packet encapsulations are processed on a node, each will need its own S-Label.  That is not generally a problems, since it is anticipated that only one encapsulation type intented for carriage as a DetNet flow will be present on any egress.  However, IPv4 and IPv6 have different forwarding equivalence classes (FEC) in MPLS and are therefore allocated different labels rather than being distinguished through the IP version field in the IP header.  Futhermore IPv4 and IPv6 when running directly over Ethernet are identified via the Ethertype rather than via the IP version number.  Whilst it ought to be safe to identify the IP type though the IP version number the absence this approach in practical applications suggests that it is more conservative to distinguish between IP types through the S-Label.  Thus when the payload is IP, two S-Labels are used, one to identify an IPv4 payload and one to identify an IPv6 payload. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision  <ins> Time Protocol (PTP) IEEE1588.  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </ins> forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority