Draft: draft-ietf-detnet-ip

Commentary: Changes according to the discussion based on the circulated PDF comments . 
 Reviewed by group
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: 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).
Since no DetNet specific headers are added to support DetNet IP
flows, only the forwarding sub-layer functions are supported using
the DetNet IP defined by this document.  Service protection can be
provided on a per sub-net basis using technologies such as MPLS I-
D.ietf-detnet-dp-sol-mpls and Ethernet as specified in the IEEE 802.1
TSN task group(referred to in this document simply as IEEE802.1 TSN).
Paragraph (version A):
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, considerations that apply to providing DetNet services via
the DetNet IP data plane in dn-gen-encap-solution. ip-procs provides
the procedures for hosts and routers that support IP-based DetNet
services.
Paragraph (version B):
The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: 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 out-of-order
delivery).  Since no DetNet specific headers are added to support
DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document.  Service
protection can be provided on a per sub-net basis using technologies
such as MPLS I-D.ietf-detnet-dp-sol-mpls and Ethernet as specified in
the IEEE 802.1 TSN task group(referred to in this document simply as
IEEE802.1 TSN).
Paragraph (version B):
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, considerations that apply to providing DetNet services via
the DetNet IP data plane in dn-gen-encap-solution. ip-procs provides
the procedures for hosts and routers that support IP-based DetNet
services. ip-flow-id-info summarizes the set of information that is
needed to identify an individual DetNet flow.
Paragraph (version B):
Note, that fig_ip_detnet_simple and fig_non_detnet_ip can be
combined, so IP DetNet End Systems can communicate over DetNet IP
network with IP End System.
Paragraph (version A):
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow.  When
forwarding packets, this means that packets are appropriately shaped
on transmission and received appropriate traffic treatment on the
connected sub-network, see QoS and detrouting for more details.  When
receiving packets, this means that there are appropriate local node
resources, e.g., buffers, to receive and process a DetNet flow
packets.
Paragraph (version B):
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow.  When
forwarding packets, this means that packets are appropriately shaped
on transmission and received appropriate traffic treatment on the
connected sub-network, see QoS and dn_dom_spec_cons for more details.
When receiving packets, this means that there are appropriate local
node resources, e.g., buffers, to receive and process a DetNet flow
packets.
Paragraph (version A):
Within a DetNet domain, the DetNet enabled IP Routers interconnect
links and sub-networks to support end-to-end delivery of DetNet
flows.  From a DetNet architecture perspective, these routers are
DetNet relays, as they must be DetNet service aware.  Such routers
identify DetNet flows based on the IP 6-tuple, and ensure that the
DetNet service required traffic treatment is provided both on the
node and on any attached sub-network.
Paragraph (version B):
Within a DetNet domain, the DetNet enabled IP Routers are
interconnected by links and sub-networks to support end-to-end
delivery of DetNet flows.  From a DetNet architecture perspective,
these routers are DetNet relays, as they must be DetNet service
aware.  Such routers identify DetNet flows based on the IP 6-tuple,
and ensure that the DetNet service required traffic treatment is
provided both on the node and on any attached sub-network.
Paragraph (version A):
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means.  This implies
each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out
the required mapping within a node.
Paragraph (version B):
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means.  This implies
each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 6-tuple to find out the
required mapping within a node.
Paragraph (version A):
As noted earlier, the Service Protection is done within each link /
sub-network independently using the domain specific mechanisms (due
the lack of a unified end to end sequencing information that would be
available for intermediate nodes).  Therefore, service protection (if
enabled) cannot be provided end-to-end, only within sub-networks.
This is shown for a three sub-network scenario in
fig_pref_in_subnets, where each sub-network can provide service
protection between its borders.
Paragraph (version B):
As noted earlier, the Service Protection is done within each link /
sub-network independently using the domain specific mechanisms (due
the lack of a unified end to end sequencing information that would be
available for intermediate nodes).  Therefore, service protection (if
enabled) cannot be provided end-to-end, only within sub-networks.
This is shown for a three sub-network scenario in
fig_pref_in_subnets, where each sub-network can provide service
protection between its borders.  "R" and "E" denotes replication and
elimination points within the sub-network.
Paragraph (version B):
OAM consideration are out-of-scope in this document.
Paragraph (version A):
The ability to aggregate individual flows, and their associated
resource control, into a larger aggregate is an important technique
for improving scaling of messaging in the data, management and
control planes.  This document identifies the traffic identification
related aspects of aggregation of DetNet flows.  The resource control
and management aspects of aggregation (including the queuing/shaping/
policing implications) will be covered in other documents.  The data
plane implications of aggregation are independent for PW/MPLS and IP
encapsulated DetNet flows.
Paragraph (version A):
DetNet flows forwarded via IP have more limited aggregation options,
due to the available traffic flow identification fields of the IP
solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
Paragraph (version A):
In both the MPLS and IP cases, additional details of the traffic
control capabilities needed at a DetNet-aware node may be covered in
the new service descriptions mentioned above or in separate future
documents.  Management and control plane mechanisms will also need to
ensure that the service required on the aggregate flow (H-LSP or
DSCP) are provided, which may include the discarding or remarking
mentioned in the previous sections.
Paragraph (version A):
aggregation and ip-agg discuss the use of flow aggregation in DetNet.
Flow aggregation can be accomplished using any of the 6-tuple fields
defined in ip-flow-id, using a DSCP identified traffic class or other
field.  It will be the responsibility of the DetNet controller plane
to be able to properly provision the use of these aggregation
mechanisms.
Paragraph (version B):
Flow aggregation can be accomplished using any of the 6-tuple fields
defined in ip-flow-id, using a DSCP identified traffic class or other
field.  It will be the responsibility of the DetNet controller plane
to be able to properly provision the use of these aggregation
mechanisms.
Paragraph (version B):
The ability to aggregate individual flows, and their associated
resource control, into a larger aggregate is an important technique
for improving scaling of messaging in the data, management and
control planes.  The resource control and management aspects of
aggregation (including the queuing/shaping/policing implications)
will be covered in other documents.  The data plane implications of
aggregation are independent of encapsulation formats.
Paragraph (version B):
DetNet flows forwarded via IP have more limited aggregation options,
due to the available traffic flow identification fields of the IP
solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated flows are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
Paragraph (version B):
Additional details of the traffic control capabilities needed at a
DetNet-aware node may be covered in separate future documents.
Management and control plane mechanisms will also need to ensure that
the service required on the aggregate flow are provided, which may
include the discarding or remarking mentioned in the previous
sections.
Paragraph (version A):
DetNet IP data plane establishment and operational procedures also
have requirements on the control and management systems for DetNet
flows and these are covered in this section.  Specifically this
section identifies a number of information elements that require
support via the management and control interfaces supported by a
DetNet node.  The specific mechanism used for such support is out of
the scope of this document.  A summary of the requirements for
management and control related information is included.  Conformance
language is not used in the summary since applies to future
mechanisms such as those that may be provided in YANG models [YANG-
REF-TBD].
Paragraph (version B):
DetNet IP data plane establishment and operational procedures also
have requirements on the control and management systems for DetNet
flows and these are referred in this section.  Specifically this
section identifies a number of information elements that require
support via the management and control interfaces supported by a
DetNet node.  The specific mechanism used for such support is out of
the scope of this document.  A summary of the requirements for
management and control related information is included.  Conformance
language is not used in the summary since applies to future
mechanisms such as those that may be provided in YANG models I-
D.ietf-detnet-yang.
Paragraph (version A):
The above implies that management and control functions will be
defined to support this requirement, e.g., see [YANG-REF-TBD].
Paragraph (version A):
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via [YANG-REF-TBD].
General information on DetNet service can be found in I-D.ietf-
detnet-flow-information-model.  Typical mechanisms used to provide
different treatment to different flows includes the allocation of
system resources (such as queues and buffers) and provisioning or
related parameters (such as shaping, and policing).  Support can also
be provided via an underlying network technology such as MPLS I-
D.ietf-detnet-ip-over-mpls.  and IEEE802.1 TSN I-D.ietf-ip-over-tsn.
Other than in the TSN case, the specific mechanisms used by a DetNet
node to ensure DetNet service delivery requirements are met for
supported DetNet flows is outside the scope of this document.
Paragraph (version B):
The above implies that management and control functions will be
defined to support this requirement, e.g., see I-D.ietf-detnet-yang.
Paragraph (version B):
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via I-D.ietf-detnet-
yang.  General information on DetNet service can be found in I-
D.ietf-detnet-flow-information-model.  Typical mechanisms used to
provide different treatment to different flows includes the
allocation of system resources (such as queues and buffers) and
provisioning or related parameters (such as shaping, and policing).
Support can also be provided via an underlying network technology
such as MPLS I-D.ietf-detnet-ip-over-mpls.  and IEEE802.1 TSN I-
D.ietf-ip-over-tsn.  Other than in the TSN case, the specific
mechanisms used by a DetNet node to ensure DetNet service delivery
requirements are met for supported DetNet flows is outside the scope
of this document.
Paragraph (version B):
IPsec Header SPI field.  Exact matching is required.
Paragraph (version A):
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.ietf-detnet-security.  Other
security considerations will be added in a future version of this
draft.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  This section considers exclusively security
considerations which are specific to the DetNet data plane.
Paragraph (version B):
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
Paragraph (version B):
The primary considerations for the data plane is to maintain
confidentiality of data 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 by MACSec
IEEE802.1AE-2018 for Ethernet (Layer-2) flows.
Paragraph (version B):
DetNet flows are identified on a per-flow basis, which may provide
attackers with additional information about the data flows (when
compared to networks that do not include per-flow identification).
This is an inherent property of DetNet which has security
implications that should be considered when determining if DetNet is
a suitable technology for any given use case.
Paragraph (version B):
To provide uninterrupted availability of the DetNet quality of
service, provisions can be made against DOS attacks and delay
attacks.  To protect against DOS attacks, excess traffic due to
malicious or malfunctioning devices can be prevented or mitigated,
for example through the use of traffic admission control applied at
the input of a DetNet domain.  To prevent DetNet packets from being
delayed by an entityexternal to a DetNet domain, DetNet technology
definition can allow for the mitigation of Man-In-The-Middle attacks,
for example through use of authentication and authorization of
devices within the DetNet domain.
Paragraph (version B):
Because DetNet mechanisms or applications that rely on DetNet can
make heavy use of methods that require precise time synchronization,
the accuracy, availability, and integrity of time synchronization is
of critical importance.  Extensive discussion of this topic can be
found in RFC7384.