Change:
New section 5, and capitalized headings.
Lou, Yes, I'll make that change. Cheers, Andy
And done.
Thanks.... Lou PS you might want to turn off line wrap in your editor...
Lou, I just checked the settings and I don't believe it's doing any hard wrapping. What are you seeing? Cheers, Andy
right - it's best to use hard wrapping for maximum editor independence as well as github reviews. Lou
Balázs, This is similar to the text in the MPLS document, but that document references SR-MPLS. In the IP case, I figured that SR-MPLS was off the table, so I changed the reference to SRv6. The earlier part of the sentence already references control plane signaling, centralized management, and hybrid solutions. In addition to those, I wanted to include the fact that SRv6 is also a valid solution here. If there's anything else that you would like to include, we can certainly add that. Cheers, Andy

Discussion:
4.6. <del> Quality of Service (QoS) mechanisms for flow specific traffic </del> <ins> Quality of Service (QoS) mechanisms for flow-specific traffic </ins> treatment typically includes a guarantee/agreement for the service, and allocation of resources to support the service.  Example QoS mechanisms include discrete resource allocation, admission control,

5. <del> [Editor's note: This section to be updated.] While management plane and control plane are traditionally considered separately, from the Data Plane perspective there is no practical difference based on the origin of flow provisioning information. This document therefore does not distinguish between information provided by a control plane protocol, e.g., RSVP-TE RFC3209 and RFC3473, or by a network management mechanisms, e.g., RestConf RFC8040 and YANG RFC7950. [Editor's note: This section is a work in progress.  discuss here what kind of enhancements are needed for DetNet and specifically for PREOF and DetNet zero congest loss and latency control.  Need to cover both traffic control (queuing) and connection control (control plane).] </del> <ins> While management plane and control planes are traditionally considered separately, from the Data Plane perspective there is no practical difference based on the origin of flow provisioning information, and the DetNet architecture I-D.ietf-detnet-architecture refers to these collectively as the 'Controller Plane'.  This document therefore does not distinguish between information provided by distributed control plane protocols, e.g., IGP routing protocols, or by centralized network management mechanisms, e.g., RestConf RFC8040, YANG RFC7950, and the Path Computation Element Communication Protocol (PCEP) RFC8283 I-D.ietf-teas-pce-native-ip or any combination thereof.  Specific considerations and requirements for the DetNet Controller Plane are discussed in control-management- requirements. </ins> 5.1. <del> [Editor's note: this is TBD.] </del> <ins> sec_dt_dp introduces the use of the IP "6-tuple" for flow identification, and QoS goes on to discuss how identified flows use specific QoS mechanisms for flow-specific traffic treatment, including path control and resource allocation. ip-flow-id contains detailed DetNet IP flow identification procedures.  Flow identification will play an important role for the DetNet controller plane. aggregation and agg-con discuss the use of flow aggregation in DetNet.  Flow aggregation can be accomplished using any of the 6-tuple fields defined in ip-flow-id, using a DSCP identified traffic class or other field.  It will be the responsibility of the DetNet controller plane to be able to properly provision the use of these aggregation mechanisms.  These requirements are included in control- management-requirements. </ins> 5.2. <del> [Editor's note: this is TBD.] </del> <ins> Explicit routes are used to ensure that packets are routed through the resources that have been reserved for them, and hence provide the DetNet application with the required service.  A requirement for the DetNet Controller Plane will be the ability to assign a particular identified DetNet IP flow to a path through the DetNet domain that has been assigned the required nodal resources to provide the appropriate traffic treatment for the flow, and also to include particular links as a part of the path that are able to support the DetNet flow, for example by using IEEE 802.1 TSN links (as discussed in mapping-tsn).  Further considerations and requirements for the DetNet Controller Plane are discussed in control-management- requirements. Whether configuring, calculating and instantiating these routes is a single-stage or multi-stage process, or in a centralized or distributed manner, is out of scope of this document. There are several of approaches that could be used to provide explicit routes and resource allocation in the DetNet layer.  For example: The path could be explicitly set up by a controller which calculates the path and explicitly configures each node along that path with the appropriate forwarding and resource allocation information. The path could be implemented using IPv6-based segment routing when extended to support resource allocation. See control-management-requirements for further discussion of these alternatives.  In addition, RFC2386 contains useful background information on QoS-based routing, and RFC5575 discusses a specific mechanism used by BGP for traffic flow specification and policy-based routing. </ins> 5.3. <del> [Editor's note: this is TBD.] </del> <ins> As discussed in sec_intro, this document does not specify the mechanisms needed to eliminate contention loss or reduce jitter for DetNet flows at the DetNet forwarding sub-layer.  The ability to manage node and link resources to be able to provide these functions will be a necessary part of the DetNet controller plane.  It will also be necessary to be able to control the required queuing mechanisms used to provide these functions along a flow's path through the network.  See ip-svc and control-management-requirements for further discussion of these requirements. </ins> 5.4. <del> [Editor's note: this is TBD.] </del> <ins> Some DetNet applications generate bidirectional traffic.  Although this document discusses the DetNet IP data plane, MPLS definitions RFC5654 are useful to illustrate terms such as associated bidirectional flows and co-routed bidirectional flows.  MPLS defines a point-to-point associated bidirectional LSP as consisting of two unidirectional point-to-point LSPs, one from A to B and the other from B to A, which are regarded as providing a single logical bidirectional forwarding path.  This is analogous to standard IP routing.  MPLS defines a point-to-point co-routed bidirectional LSP as an associated bidirectional LSP which satisfies the additional constraint that its two unidirectional component LSPs follow the same path (in terms of both nodes and links) in both directions.  An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate.  In both types of bidirectional LSPs, resource reservations may differ in each direction.  The concepts of associated bidirectional flows and co- routed bidirectional flows can also be applied to DetNet IP flows. While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than the need for the two directions of a co- routed bidirectional flow to take the same path.  That is to say that bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane.  Fate sharing and associated vs. co- routed bidirectional flows can be managed at the control level. Control and management mechanisms will need to support bidirectional flows, but the specification of such mechanisms are out of scope of this document.  An example control plane solution for MPLS can be found in RFC7551. This is further discussed in control-management-requirements. </ins> 5.5. <del> [Editor's note: This is managed at the management plane or controller level.] Some DetNet applications generate bidirectional traffic.  While the DetNet data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than need for the two directions take the same paths.  That is to say that bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane.  Fate sharing and associated vs co-routed bidirectional flows can be managed at the control level. Note, that there is no stated requirement for bidirectional DetNet flows to be supported using the same 6-tuple in each direction. Control mechanisms will need to support such bidirectional flows but such mechanisms are out of scope of this document.  An example control plane solution for MPLS can be found in RFC7551. </del> <ins> While the definition of controller plane for DetNet is out of the scope of this document, there are particular considerations and requirements for such that result from the unique characteristics of the DetNet architecture I-D.ietf-detnet-architecture and data plane as defined herein. The primary requirements of the DetNet controller plane are that it must be able to: Instantiate DetNet flows in a DetNet domain (which may include some or all of explicit path determination, link bandwidth reservations, restricting flows to IEEE 802.1 TSN links, node buffer and other resource reservations, specification of required queuing disciplines along the path, ability to manage bidirectional flows, etc.) as needed for a flow. The ability to support DetNet flow aggregation Advertise static and dynamic node and link resources such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches) Scale to handle a large number of DetNet flows in a domain (which may require per-flow signaling or provisioning) Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the network and the DetNet functionality. These requirements, as stated earlier, could be satisfied using distributed control protocol signaling, centralized network management provisioning mechanisms, or hybrid combinations of the two, and could also make use of IPv6-based segment routing. In the abstract, the results of either distributed signaling or centralized provisioning are equivalent from a DetNet data plane perspective - flows are instantiated, explicit routes are determined, resources are reserved, and packets are forwarded through the domain using the IP data plane. However, from a practical and implementation standpoint, they are not equivalent at all.  Some approaches are more scalable than others in terms of signaling load on the network.  Some can take advantage of global tracking of resources in the DetNet domain for better overall network resource optimization.  Some are more resilient than others if link, node, or management equipment failures occur.  While a detailed analysis of the control plane alternatives is out of the scope of this document, the requirements from this document can be used as the basis of a later analysis of the alternatives. </ins> 6.

6.4. <del> The use of prefixes, wildcards, bimasks, and port ranges allows a </del> <ins> The use of prefixes, wildcards, bitmasks, and port ranges allows a </ins> DetNet node to aggregate DetNet flows.  This aggregation can take place within a single node, when that node maintains state about both the aggregated and component flows.  It can also take place between