Change:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)

Discussion:
also support the imposition and disposition of the required DetNet encapsulation.  These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In <del> this example TSN Streams are simple applicaions over DetNet flows. </del> <ins> this example TSN Streams are simple applications over DetNet flows. </ins> The specific of this operation are discussed later in this document. In this example, edge nodes provide a service proxy function that

4.2. <del> The basic encapsulation approach is to treat a TSN Stream as an app- </del> <ins> The basic encapsulation approach is to treat a TSN Stream as an App- </ins> flow from the DetNet MPLS perspective.  The corresponding example shown in fig_tsn_mpls_ex.

bridged networks.  IEEE8021CB defines packet replication and elimination functions for a TSN network. <ins> The implementation of TSN entity (i.e., TSN packet processing functions) MUST be compliant with the relevant IEEE 802.1 standards. </ins> TSN specific functions are executed on the data received by the DetNet Edge Node from the connected CE before forwarded to connected CE(s) or presentation to the DetNet Service Proxy function for

DetNet PW by a PE before it is output on the Attachment Circuit(s) (AC). <del> TSN specific function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions must be supported. </del> <ins> TSN packet processing function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions are supported. </ins> When a PE receives a packet from a CE, on a given AC with DetNet <del> service, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del> <ins> service, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected CE(s)

flooding the PE MUST drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service <del> Proxy, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del> <ins> Proxy, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.). Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected

The Service Proxy function maps between App-flows and DetNet flows. The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined <del> in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </del> <ins> in Clause 6. and Clause 9. of IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </ins> When a DetNet Service Proxy receives a packet from the TSN Entity it MUST check whether such an App-flow is present in its mapping table.

based on the origin of flow mapping related information (management plane or control plane). <ins> The following summarizes the set of information that is needed to configure TSN over DetNet MPLS: TSN related configuration information according to the TSN role of the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. DetNet MPLS related configuration information according to the DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls. App-Flow identification information to map received TSN Stream(s) to the DetNet flow.  Parameters fo TSN stream identification are defined in IEEE8021CB and IEEEP8021CBdb. This information MUST be provisioned per DetNet flow. </ins> MPLS DetNet Edge nodes are member of both the DetNet domain and the connected TSN network.  From the TSN network perspective the MPLS (DetNet) Edge node has a "TSN relay node" role, so TSN specific

Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are <del> described in RFC8655.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and/or by an underlying sub-net using MACSec IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows. </del> <ins> described in RFC8655. DetNet MPLS data plane specific considerations are summarized and described in I-D.ietf-detnet-mpls including any application flow types.  This document focuses on the scenario where TSN Streams are the application flows for DetNet and it is already covered by those DetNet MPLS data plane security considerations. </ins> 8.