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

Commentary: Comments resolved : Routing Directorate 
 I approved these . The Changes looked good to me . I opened a small pull request to fix commas .
Paragraph (version A):
This document specifies the Deterministic Networking MPLS data plane
when operating over a TSN sub-network.  This document does not define
new procedures or processes.  Whenever this document makes
requirements statements or recommendations, these are taken from
normative text in the referenced RFCs.
Paragraph (version A):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows with a low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in RFC8655.
Paragraph (version B):
This document specifies the Deterministic Networking MPLS data plane
when operating over an IEEE 802.1 Time-Sensitive Networking (TSN)
sub-network.  This document does not define new procedures or
processes.  Whenever this document makes requirements statements or
recommendations, these are taken from normative text in the
referenced RFCs.
Paragraph (version B):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows with low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in RFC8655.
Paragraph (version A):
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection and reordering.  The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering) leveraging MPLS Traffic Engineering mechanisms.
Paragraph (version A):
I-D.ietf-detnet-mpls specifies the DetNet data plane operation for
MPLS-based Packet Switched Network (PSN).  MPLS encapsulated DetNet
flows can be carried over network technologies that can provide the
DetNet required level of service.  This document focuses on the
scenario where MPLS (DetNet) nodes are interconnected by a IEEE 802.1
TSN sub-network.
Paragraph (version A):
This document uses the terminology established in the DetNet
architecture RFC8655 and I-D.ietf-detnet-mpls, and the reader is
assumed to be familiar with that document and its terminology.
Paragraph (version B):
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection and reordering.  The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited
reordering) leveraging MPLS Traffic Engineering mechanisms.
Paragraph (version B):
RFC8964 specifies the DetNet data plane operation for MPLS-based
Packet Switched Network (PSN).  MPLS encapsulated DetNet flows can be
carried over network technologies that can provide the DetNet
required level of service.  This document focuses on the scenario
where MPLS (DetNet) nodes are interconnected by a IEEE 802.1 TSN sub-
network.  There is close cooperation between the IETF DetNet WG and
the IEEE 802.1 TSN TG.
Paragraph (version B):
This document uses the terminology established in the DetNet
architecture RFC8655 and RFC8964.  TSN specific terms are defined in
the TSN TG of IEEE 802.1 Working Group.  The reader is assumed to be
familiar with these documents and their terminology.
Paragraph (version B):
Aggregation label, a special case of an S-Label.
Paragraph (version B):
Forwarding label that identifies the LSP used by a DetNet flow.
Paragraph (version A):
A node operating on a DetNet flow in the Detnet service sub-layer,
i.e.  a node processing a DetNet packet which has the S-Label as top
of stack uses the local context associated with that S-Label, for
example a received F-Label, to determine what local DetNet
operation(s) are applied to that packet.  An S-Label may be unique
when taken from the platform label space RFC3031, which would enable
correct DetNet flow identification regardless of which input
interface or LSP the packet arrives on.  The service sub-layer
functions (i.e., PREOF) use a DetNet control word (d-CW).
Paragraph (version A):
The DetNet MPLS data plane builds on MPLS Traffic Engineering
encapsulations and mechanisms to provide a forwarding sub-layer that
is responsible for providing resource allocation and explicit routes.
The forwarding sub-layer is supported by one or more forwarding
labels (F-Labels).
Paragraph (version B):
Service label.
Paragraph (version B):
A node operating on a DetNet flow in the Detnet service sub-layer,
i.e.  a node processing a DetNet packet which has the S-Label as top
of stack uses the local context associated with that service label
(S-Label), for example a received forwarding label (F-Label), to
determine what local DetNet operation(s) are applied to that packet.
An S-Label may be unique when taken from the platform label space
RFC3031, which would enable correct DetNet flow identification
regardless of which input interface or LSP the packet arrives on.
The service sub-layer functions (i.e., PREOF) use a DetNet control
word (d-CW).
Paragraph (version B):
The DetNet MPLS data plane builds on MPLS Traffic Engineering
encapsulations and mechanisms to provide a forwarding sub-layer that
is responsible for providing resource allocation and explicit routes.
The forwarding sub-layer is supported by one or more F-Labels.
Paragraph (version A):
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments
to IEEE8021Q that provide zero congestion loss and bounded latency in
bridged networks.  Furthermore IEEE8021CB defines frame replication
and elimination functions for reliability that should prove both
compatible with and useful to, DetNet networks.  All these functions
have to identify flows those require TSN treatment.
Paragraph (version B):
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments
to IEEE8021Q that provide zero congestion loss and bounded latency in
bridged networks.  Furthermore IEEE8021CB defines frame replication
and elimination functions for reliability that should prove both
compatible with and useful to, DetNet networks.  All these functions
have to identify flows those require TSN treatment (i.e., applying
TSN functions during forwarding).
Paragraph (version A):
Placement of TSN functions depends on the TSN capabilities of nodes.
MPLS (DetNet) Nodes may or may not support TSN functions.  For a
given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated
as a Talker or a Listener inside the TSN sub-network.
Paragraph (version B):
Placement of TSN functions depends on the TSN capabilities of the
nodes along the path.  MPLS (DetNet) Nodes may or may not support TSN
functions.  For a given TSN Stream (i.e., DetNet flow) an MPLS
(DetNet) node is treated as a Talker or a Listener inside the TSN
sub-network.
Paragraph (version A):
A TSN-aware MPLS (DetNet) node impementations must support the Stream
Identification TSN component for recognizing flows.
Paragraph (version B):
A TSN-aware MPLS (DetNet) node implementation must support the Stream
Identification TSN component for recognizing flows.
Paragraph (version A):
A TSN-aware MPLS (DetNet) node implementations must support the
Sequencing function and the Sequence encode/decode function as
defined in Clause 7.4 and 7.6 of IEEE8021CB if FRER is used inside
the TSN sub-network.
Paragraph (version B):
A TSN-aware MPLS (DetNet) node implementation must support the
Sequencing function and the Sequence encode/decode function as
defined in Clause 7.4 and 7.6 of IEEE8021CB if FRER is used inside
the TSN sub-network.
Paragraph (version A):
A TSN-aware MPLS (DetNet) node implementations must support the
Stream splitting function and the Individual recovery function as
defined in Clause 7.7 and 7.5 of IEEE8021CB when the node is a
replication or elimination point for FRER.
Paragraph (version B):
A TSN-aware MPLS (DetNet) node implementation must support the Stream
splitting function and the Individual recovery function as defined in
Clause 7.7 and 7.5 of IEEE8021CB when the node is a replication or
elimination point for FRER.
Paragraph (version A):
Mapping between DetNet MPLS flow(s) (label information: A-labels,
S-labels and F-labels as defined in I-D.ietf-detnet-mpls) and TSN
Stream(s) (as stream identification information defined in
IEEEP8021CBdb).  Note, that managed objects for TSN Stream
identification can be found in IEEEP8021CBcv.
Paragraph (version A):
Mappings between DetNet and TSN management and control planes are out
of scope of the document.  Some of the challanges are highligthed
below.
Paragraph (version B):
Mapping between DetNet MPLS flow(s) (label information: A-labels,
S-labels and F-labels as defined in RFC8964) and TSN Stream(s) (as
stream identification information defined in IEEEP8021CBdb).
Note, that managed objects for TSN Stream identification can be
found in IEEEP8021CBcv.
Paragraph (version B):
Mappings between DetNet and TSN management and control planes are out
of scope of the document.  Some of the challenges are highlighted
below.
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.  This section considers
exclusively security considerations which are specific to the DetNet
MPLS over TSN sub-network scenario.
Paragraph (version B):
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 RFC8964.  This section considers exclusively
security considerations which are specific to the DetNet MPLS over
TSN sub-network scenario.
Paragraph (version A):
This document specifies the use of a DetNet MPLS network to
interconnect TSN nodes/network segments.  DetNet MPLS data plane is
defined in I-D.ietf-detnet-mpls.
Paragraph (version B):
This document specifies the use of a DetNet MPLS network to
interconnect TSN nodes/network segments.  DetNet MPLS data plane is
defined in RFC8964.
Paragraph (version A):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls.
The reader is assumed to be familiar with these documents and their
terminology.
Paragraph (version B):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655 and RFC8938, and RFC8964.  TSN specific
terms are defined in the TSN TG of IEEE 802.1 Working Group.  The
reader is assumed to be familiar with these documents and their
terminology.
Paragraph (version A):
In the figure, "Application" indicates the application payload
carried by the TSN network.  "MPLS App-Flow" indicates that the TSN
Stream is the payload from the perspective of the DetNet MPLS data
plane defined in I-D.ietf-detnet-mpls.  A single DetNet MPLS flow can
aggregate multiple TSN Streams.
Paragraph (version B):
In the figure, "Application" indicates the application payload
carried by the TSN network.  "MPLS App-Flow" indicates that the TSN
Stream is the payload from the perspective of the DetNet MPLS data
plane defined in RFC8964.  A single DetNet MPLS flow can aggregate
multiple TSN Streams.
Paragraph (version A):
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
transmission across the DetNet domain, or on the data received from a
DetNet PW by a PE before it is output on the Attachment Circuit(s)
(AC).
Paragraph (version B):
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
transmission across the DetNet domain.  TSN specific functions are
also executed on the data received from a DetNet PW by a PE before
the data is output on the Attachment Circuit(s) (AC).
Paragraph (version A):
When a PE receives a packet from a CE, on a given AC with DetNet
service, it first checks 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 are 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):
When a PE receives a packet from a CE, on a given AC with DetNet
service, it first checks 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 are 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):
If the PE decides to forward the packet, the packet MUST be forwarded
according to the TSN Stream specific configuration to connected CE(s)
(in case of local bridging) and/or to the DetNet Service Proxy (in
case of forwarding to remote CE(s) required).  If there are no TSN
Stream specific forwarding configurations the PE MUST flood the
packet to other locally attached CE(s) and to the DetNet Service
Proxy.  If the administrative policy on the PE does not allow
flooding the PE MUST drop the packet.
Paragraph (version B):
If the PE decides to forward the packet, the packet MUST be forwarded
according to the TSN Stream specific configuration to connected CE(s)
(in case of local bridging) and/or to the DetNet Service Proxy (in
case of forwarding to remote CE(s)).  If there are no TSN Stream
specific forwarding configurations the PE MUST flood the packet to
other locally attached CE(s) and to the DetNet Service Proxy.  If the
administrative policy on the PE does not allow flooding the PE MUST
drop the packet.
Paragraph (version A):
In the design of I-D.ietf-detnet-mpls an MPLS service label (the
S-Label), similar to a pseudowire (PW) label RFC3985, is used to
identify both the DetNet flow identity and the payload MPLS payload
type.  The DetNet sequence number is carried in the DetNet Control
word (d-CW) which carries the Data/OAM discriminator as well.  In I-
D.ietf-detnet-mpls two sequence number sizes are supported: a 16 bit
sequence number and a 28 bit sequence number.
Paragraph (version B):
In the design of RFC8964 an MPLS service label (the S-Label), similar
to a pseudowire (PW) label RFC3985, is used to identify both the
DetNet flow identity and the payload MPLS payload type.  The DetNet
sequence number is carried in the DetNet Control word (d-CW) which
carries the Data/OAM discriminator as well.  In RFC8964 two sequence
number sizes are supported: a 16 bit sequence number and a 28 bit
sequence number.
Paragraph (version A):
When a PE receives a packet from the Service Proxy function it MUST
handle the packet as defined in I-D.ietf-detnet-mpls.
Paragraph (version B):
When a PE receives a packet from the Service Proxy function it MUST
handle the packet as defined in RFC8964.
Paragraph (version A):
For further details on DetNet Service and Forwarding sub-layers see
I-D.ietf-detnet-mpls.
Paragraph (version B):
For further details on DetNet Service and Forwarding sub-layers see
RFC8964.
Paragraph (version A):
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.
Paragraph (version B):
DetNet MPLS data plane specific considerations are summarized and
described in RFC8964 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.
Paragraph (version A):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655, and the reader is assumed to be familiar
with that document and its terminology.
Paragraph (version B):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655.  TSN specific terms are defined in the
TSN TG of IEEE 802.1 Working Group.  The reader is assumed to be
familiar with these documents and their terminology.
Paragraph (version A):
TSN capabilities of the TSN sub-network are made available for IP
(DetNet) flows via the protocol interworking function desribed in
Annex C.5 of IEEE8021CB.  For example, applied on the TSN edge port
it can convert an ingress unicast IP (DetNet) flow to use a specific
Layer-2 multicast destination MAC address and a VLAN, in order to
direct the packet through a specific path inside the bridged network.
A similar interworking function pair at the other end of the TSN sub-
network would restore the packet to its original Layer-2 destination
MAC address and VLAN.
Paragraph (version B):
TSN capabilities of the TSN sub-network are made available for IP
(DetNet) flows via the protocol interworking function described in
Annex C.5 of IEEE8021CB.  For example, applied on the TSN edge port
it can convert an ingress unicast IP (DetNet) flow to use a specific
Layer-2 multicast destination MAC address and a VLAN, in order to
direct the packet through a specific path inside the bridged network.
A similar interworking function pair at the other end of the TSN sub-
network would restore the packet to its original Layer-2 destination
MAC address and VLAN.