Change:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?

Discussion:
1. Deterministic Networking (DetNet) is a service that can be offered by <del> a network to DetNet flows.  DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in I-D.ietf- detnet-architecture. </del> <ins> a network to DetNet flows.  DetNet provides these flows extremely an low packet loss rates and assured maximum end-to-end delivery latency.  General background and concepts of DetNet can be found in I-D.ietf-detnet-architecture. </ins> This document specifies the DetNet data plane and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched

implment also the DetNet service layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service layer. <ins> [Note to the editors this section is not needed.  This is internal to the node.  With pseudowires we needed global identifier for the control plane to identfy the PW to the node, and we used platform label space to ensure the PW was identiable when it was received. I think this can be deleted - SB] </ins> A DetNet Edge and Relay node internal construct that uniquely identifies a DetNet flow within a node and never appear on-wire. It may be used to select proper forwarding and/or DetNet specific

operate over multiple (separate) DetNet member flows of a DetNet compound flow. <del> A control word used for sequencing and identifying duplaicate </del> <ins> A control word used for sequencing and identifying duplicate </ins> packets at the DetNet service layer. 2.2.

ensuring congestion protection and latency control for the above listed DetNet functions. <ins> [Note to Editors.  I am not convinced that the previous para adds value.  It certainly has the opportunity to add confusion.  I think it needs to be deleted - SB] </ins> The DetNet data plane allows for the aggregation of DetNet flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When DetNet flows are aggregated, transit nodes may have limited ability to

Therefore, local-IDs has to be unique on each edge and relay nodes. Local-ID is unambiguously bound to the DetNet flow. <ins> [Note to Editor - again I think previous para needs to be removed] </ins> 4.2. DetNet service layer introduces packet replication and elimination

the packet elimination on the packet processing pipeline is implementation specific. <ins> [Note to editor - Clean up local-id when dealing with PREF text] </ins> 4.3. DetNet service layer introduces also packet reordering functionality

DetNet service Label (S-label) that identifies a DetNet flow to the peer node that is to process it.  The S-Label is allocated <del> from the platform label space. </del> <ins> from the platform label space RFC3031. </ins> Zero or more MPLS transport LSP label(s) (T-label) used to direct the packet along the label switched path (LSP) to the next peer

6.4. DetNet flow identification at a DetNet service layer is realized by <del> an S-label.  It maps a Detnet flow to a specific d-CW in a DetNet node.  For a data flow the S-label used for flow identification MUST be bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. An S-label for a single DetNet flow does not need to be unique DetNet domain wide.  As long as two or more different DetNet flows do not errorneously map to a same d-CW in a DetNet node the labels may vary. </del> <ins> an S-label.  The S-lable is allocated from the platform label label space RFC3031 Thich means that the DetNet flow is correctly identified and matched to the flow parameters, including the flow history, regardless of which input interface the packet arrives on. The S-label MUST be at the bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. The S-label for a specific DetNet flow is unique to that DetNet flow on a specific node, but is not required to be identical with the S-lable for that DetNet flow in any other node within the DetNet domain.  Thus the S-label can only be used to identify the DetNet flow at the intended receiving node. </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