Draft: draft-ietf-detnet-tsn-vpn-over-mpls

Commentary: Fixing conformance language Adding more definite references for TSN functions ( i.e. , Clause numbers )
Paragraph (version A):
fig_tsn_mpls_detnet shows IEEE 802.1 TSN end stations operating over
a TSN aware DetNet service running over an MPLS network.  DetNet Edge
Nodes sit at the boundary of a DetNet domain.  They are responsible
for mapping non-DetNet aware L2 traffic to DetNet services.  They
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
this example TSN Streams are simple applicaions over DetNet flows.
The specific of this operation are discussed later in this document.
Paragraph (version B):
fig_tsn_mpls_detnet shows IEEE 802.1 TSN end stations operating over
a TSN aware DetNet service running over an MPLS network.  DetNet Edge
Nodes sit at the boundary of a DetNet domain.  They are responsible
for mapping non-DetNet aware L2 traffic to DetNet services.  They
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
this example TSN Streams are simple applications over DetNet flows.
The specific of this operation are discussed later in this document.
Paragraph (version B):
The implementation of TSN entity (i.e., TSN packet processing
functions) MUST be compliant with the relevant IEEE 802.1 standards.
Paragraph (version A):
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.
Paragraph (version A):
When a PE receives a packet from a CE, on a given AC with DetNet
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.
Paragraph (version B):
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.
Paragraph (version B):
When a PE receives a packet from a CE, on a given AC with DetNet
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.
Paragraph (version A):
When a TSN entity of the PE receives a packet from the DetNet Service
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.
Paragraph (version B):
When a TSN entity of the PE receives a packet from the DetNet Service
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version B):
TSN related configuration information according to the TSN role of
the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and
IEEEP8021CBdb.
Paragraph (version B):
DetNet MPLS related configuration information according to the
DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls.
Paragraph (version B):
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.
Paragraph (version B):
This information MUST be provisioned per DetNet flow.
Paragraph (version A):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
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.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.
Paragraph (version B):
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.