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

Commentary: Work In progress - Wanted to get the figure changes out for review . Need to check if the overly wording is complete . There was a lot of inter working text - I have commented out .
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 they understand and support IEEE 802.1 TSN and are able
to map TSN Streams into DetNet flows.  The specific of this operation
are discussed later in this document.
Paragraph (version A):
In this example, edge nodes provide a service proxy function that
"associates" the DetNet flows and native flows (i.e., TSN Streams) at
the edge of the DetNet domain.  This ensures that the DN Flow is
properly served at the Edge node (and inside the domain).
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 applicaions over DetNet flows.
The specific of this operation are discussed later in this document.
Paragraph (version B):
In this example, edge nodes provide a service proxy function that
"associates" the DetNet flows and native flows (i.e., TSN Streams) at
the edge of the DetNet domain.  TSN streams are treated as App-flows
for DetNet.  The whole DetNet domain behaves as a TSN relay node for
the TSN streams.  The service proxy behaves as a port of that TSN
relay node.
Paragraph (version A):
The Service Proxy function maps between App-flows and DetNet flows.
It 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.
Paragraph (version A):
Implementations of this document SHALL use management and control
information to map a TSN Stream to a DetNet flow.  N:1 mapping
(aggregating TSN Streams in a single DetNet flow) SHALL be supported.
The management or control function that provisions flow mapping SHALL
ensure that adequate resources are allocated and configured to
provide proper service requirements of the mapped flows.
Paragraph (version B):
The Service Proxy function maps between App-flows and DetNet flows.
The DetNet Edge Node TSN function 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):
Implementations of this document SHALL use management and control
information to map a TSN Stream to a DetNet flow.  N:1 mapping
(aggregating multiple TSN Streams in a single DetNet flow) SHALL be
supported.  The management or control function that provisions flow
mapping SHALL ensure that adequate resources are allocated and
configured to provide proper service requirements of the mapped
flows.
Paragraph (version B):
A MPLS DetNet flow is configured to carry any number of TSN flows.
The DetNet flow specific bandwidth profile SHOULD match the required
bandwidth of the App-flow aggregate.
Paragraph (version A):
In order to use a DetNet network to interconnect TSN segments, TSN
specific information must be converted to DetNet domain specific
ones.  TSN Stream ID(s) and stream(s) related parameters/requirements
must be converted to a DetNet flow-ID and flow related parameters/
requirements.  Note that, as the DetNet network is just a portion of
the end2end TSN path (i.e., single hop from Ethernet perspective),
some parameters (e.g., delay) may differ significantly.  Other
parameters (like bandwidth) also may have to be tuned due to the MPLS
encapsulation used within the DetNet network.
Paragraph (version B):
Note that, as the DetNet network is just a portion of the end to end
TSN path (i.e., single hop from Ethernet perspective), some
parameters (e.g., delay) may differ significantly.  Since there is no
interworking function the bandwidth of DetNet network is assumed to
be set large enough to handle all TSN Flows it will support.  At the
egress of the Detnet Domain the MPLS headers are stripped and the TSN
flow continues on as a normal TSN flow.
Paragraph (version B):
In order to use a DetNet network to interconnect TSN segments, TSN
specific information must be converted to DetNet domain specific
ones.  TSN Stream ID(s) and stream(s) related parameters/requirements
must be converted to a DetNet flow-ID and flow related parameters/
requirements.
Paragraph (version A):
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.ietf-detnet-security.  DetNet MPLS
data plane specific considerations are summarized in I-D.ietf-detnet-
mpls.  Encryption may provided within the TSN network using MACSec
IEEE802.1AE-2018.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in I-D.ietf-detnet-architecture.  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.