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

Commentary: Update references , fix nits , fix one minor change as discussed on list ( IP doc ) add new revisions for submission to IESG : ip , mpls , ip - over - mpls , mpls - over - udp - ip 
 please merge and upload mpls / IDs / draft - ietf - detnet - mpls- mpls - over - udp - ip / IDs / draft - ietf - detnet - mpls - over - udp - ip- ip - over - mpls / IDs / draft - ietf - detnet - ip - over - mpls- ip / IDs / draft - ietf - detnet - ip- 
 OK . Thanks for the updates . B.
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 I-D.ietf-
detnet-architecture.
Paragraph (version B):
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 A):
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture and I-D.ietf-detnet-mpls,
and the reader is assumed to be familiar with that document and its
terminology.
Paragraph (version B):
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 A):
As described in the DetNet architecture I-D.ietf-detnet-architecture
and also illustrated here in fig_mpls_detnet_part a sub-network
provides from MPLS perspective a single hop connection between MPLS
(DetNet) nodes.  Functions used for resource allocation and explicit
routes are treated as domain internal functions and does not require
function interworking across the DetNet MPLS network and the TSN sub-
network.
Paragraph (version B):
As described in the DetNet architecture RFC8655 and also illustrated
here in fig_mpls_detnet_part a sub-network provides from MPLS
perspective a single hop connection between MPLS (DetNet) nodes.
Functions used for resource allocation and explicit routes are
treated as domain internal functions and does not require function
interworking across the DetNet MPLS network and the TSN sub-network.
Paragraph (version A):
The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
Working Group deals with deterministic services through IEEE 802
networks.  Deterministic Networking (DetNet) defined by IETF is a
service that can be offered by a L3 network to DetNet flows.  General
background and concepts of DetNet can be found in I-D.ietf-detnet-
architecture.
Paragraph (version B):
The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
Working Group deals with deterministic services through IEEE 802
networks.  Deterministic Networking (DetNet) defined by IETF is a
service that can be offered by a L3 network to DetNet flows.  General
background and concepts of DetNet can be found in RFC8655.
Paragraph (version A):
This document uses the terminology and concepts established in the
DetNet architecture I-D.ietf-detnet-architecture and I-D.ietf-detnet-
data-plane-framework, 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 I-D.ietf-detnet-data-plane-framework,
and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with
these documents and their terminology.
Paragraph (version A):
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.
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 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 A):
This document uses the terminology and concepts established in the
DetNet architecture I-D.ietf-detnet-architecture and I-D.ietf-detnet-
data-plane-framework, and 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 I-D.ietf-detnet-data-plane-framework,
and the reader is assumed to be familiar with these documents and
their terminology.
Paragraph (version A):
This draft does not have additional security considerations.
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.  MPLS and IP specific
considerations are described in I-D.ietf-detnet-mpls and I-D.ietf-
detnet-ip.
Paragraph (version B):
This draft does not have additional security considerations.
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  MPLS and IP specific considerations are
described in I-D.ietf-detnet-mpls and I-D.ietf-detnet-ip.
Paragraph (version A):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in I-D.ietf-
detnet-architecture.
Paragraph (version B):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows extremely 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):
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture and the the DetNet Data
Plane Framework I-D.ietf-detnet-data-plane-framework.  The reader is
assumed to be familiar with these documents and any terminology
defined therein.
Paragraph (version B):
This document uses the terminology established in the DetNet
architecture RFC8655 and the the DetNet Data Plane Framework I-
D.ietf-detnet-data-plane-framework.  The reader is assumed to be
familiar with these documents and any terminology defined therein.
Paragraph (version A):
In addition to explicit routes, and packet replication and
elimination, described in dn-dt-solution above, DetNet provides zero
congestion loss and bounded latency and jitter.  As described in I-
D.ietf-detnet-architecture, there are different mechanisms that maybe
used separately or in combination to deliver a zero congestion loss
service.  This includes Quality of Service (QoS) mechanisms at the
MPLS layer, that may be combined with the mechanisms defined by the
underlying network layer such as 802.1TSN.
Paragraph (version B):
In addition to explicit routes, and packet replication and
elimination, described in dn-dt-solution above, DetNet provides zero
congestion loss and bounded latency and jitter.  As described in
RFC8655, there are different mechanisms that maybe used separately or
in combination to deliver a zero congestion loss service.  This
includes Quality of Service (QoS) mechanisms at the MPLS layer, that
may be combined with the mechanisms defined by the underlying network
layer such as 802.1TSN.
Paragraph (version A):
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.  This section considers
exclusively security considerations which are specific to the DetNet
MPLS data plane.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  This section considers exclusively security
considerations which are specific to the DetNet MPLS data plane.
Paragraph (version A):
DetNet (Deterministic Networking) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency.  A description of the general background and
concepts of DetNet can be found in I-D.ietf-detnet-architecture.
Paragraph (version B):
DetNet (Deterministic Networking) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency.  A description of the general background and
concepts of DetNet can be found in RFC8655.
Paragraph (version A):
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture, and the reader is assumed
to be familiar with that document and its terminology.
Paragraph (version B):
This document uses the terminology established in the DetNet
architecture RFC8655, and the reader is assumed to be familiar with
that document and its terminology.
Paragraph (version A):
This document describes how application flows, or app-flows, are
carried over DetNet networks.  The DetNet Architecture, I-D.ietf-
detnet-architecture, models the DetNet related data plane functions
as decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer.
Paragraph (version A):
ProtStack1 reproduced from the I-D.ietf-detnet-architecture,shows a
logical DetNet service with the two sub-layers.
Paragraph (version B):
This document describes how application flows, or app-flows, are
carried over DetNet networks.  The DetNet Architecture, RFC8655,
models the DetNet related data plane functions as decomposed into two
sub-layers: a service sub-layer and a forwarding sub-layer.
Paragraph (version B):
ProtStack1 reproduced from the RFC8655,shows a logical DetNet service
with the two sub-layers.
Paragraph (version A):
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.
Paragraph (version B):
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 RFC8655 and data plane as defined herein.
Paragraph (version A):
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., RSVP-TE RFC3209 and
RFC3473, or by centralized network management mechanisms, e.g.,
RestConf RFC8040, YANG RFC7950, and the Path Computation Element
Communication Protocol (PCEP) I-D.ietf-pce-pcep-extension-for-pce-
controller or any combination thereof.  Specific considerations and
requirements for the DetNet Controller Plane are discussed in
control-management-requirements.
Paragraph (version B):
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 RFC8655 refers to these
collectively as the 'Controller Plane'.  This document therefore does
not distinguish between information provided by distributed control
plane protocols, e.g., RSVP-TE RFC3209 and RFC3473, or by centralized
network management mechanisms, e.g., RestConf RFC8040, YANG RFC7950,
and the Path Computation Element Communication Protocol (PCEP) I-
D.ietf-pce-pcep-extension-for-pce-controller or any combination
thereof.  Specific considerations and requirements for the DetNet
Controller Plane are discussed in control-management-requirements.
Paragraph (version A):
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.  This section considers
general security considerations applicable to all data planes.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  This section considers general security
considerations applicable to all data planes.
Paragraph (version A):
In order to maximize reuse of 5-tuple based mechanisms, e.g,
traceroute, DetNet-aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple.
Paragraph (version B):
In order to maximize reuse of existing mechanisms, DetNet-aware
applications and end systems SHOULD NOT mix DetNet and non-DetNet
traffic within a single 5-tuple.
Paragraph (version A):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC6434, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet associated with a DetNet flow.
Paragraph (version B):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC8504, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet associated with a 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 I-D.ietf-detnet-architecture.  This section considers
exclusively security considerations which are specific to the DetNet
IP data plane.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  This section considers exclusively security
considerations which are specific to the DetNet IP data plane.