Draft: draft-ietf-detnet-ip

Commentary: IESG review comment resolutions in this version : DONE   , (    ) , ( 03 - 09 ) , Ready with Nits   , IANA , ( 03 - 12 ) , OK   ( 03 - 12 ) ,     03 - 12 , Nits   , ( 03 - 15 ) , Comments and Many nits TO BE DISCUSSED : Security section  , ( 04 - 09 ) , decrease authors to 5 ! ! ! 
 reviewed in April 22 meeting
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 the DetNet
Architecture RFC8655.
Paragraph (version B):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows with
extremely low packet loss rates and assured maximum end-to-end
delivery latency.  General background and concepts of DetNet can be
found in the DetNet Architecture RFC8655.
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions as two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection (e.g., by packet replication and packet elimination
functions) and reordering.  The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited
out-of-order delivery).  The service sub-layer generally requires
additional fields to provide its service; for example see I-D.ietf-
detnet-mpls.  Since no DetNet-specific fields 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):
The DetNet Architecture models the DetNet related data plane
functions as two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection (e.g., by packet replication and packet elimination
functions) and reordering.  The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited
out-of-order delivery).  The service sub-layer generally requires
additional header fields to provide its service; for example see I-
D.ietf-detnet-mpls.  Since no DetNet-specific fields 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 (Time-Sensitive Networking) task group (referred
to in this document simply as IEEE802.1 TSN).
Paragraph (version A):
Non-DetNet and DetNet IP packets are identical on the wire.
Generally the fields used in flow identification are forwarded
unmodified, however modification of these fields is allowed, for
example to a DSCP value, when required by the DetNet service.
Paragraph (version B):
For some of the protocols 5-tuples and 6-tuples cannot be used
because the port information is not available (e.g., ICMP, IPSec
ESP).  Same can be valid for flow aggregates.  In such cases using
smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP
protocol) or even a 2-tuple (all IP traffic between two IP
addresses).
Paragraph (version B):
Non-DetNet and DetNet IP packets are identical on the wire.
Generally the fields used in flow identification are forwarded
unmodified, however modification of these fields is allowed, for
example changing the DSCP value, when required by the DetNet service.
Paragraph (version A):
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic those
are identified within the DetNet domain as DetNet flows, relay nodes
understand the forwarding requirements of the DetNet flow and ensure
that node, interface and sub-network resources are allocated to
ensure DetNet service requirements.  The dotted line around the
Service component of the Relay Nodes indicates that the transit
routers are DetNet service aware but do not perform any DetNet
service sub-layer function, e.g., PREOF.
Paragraph (version B):
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic that is
identified within the DetNet domain as DetNet flows.  Relay nodes
understand the forwarding requirements of the DetNet flow and ensure
that node, interface and sub-network resources are allocated to
ensure DetNet service requirements.  The dotted line around the
Service component of the Relay Nodes indicates that the transit
routers are DetNet service aware but do not perform any DetNet
service sub-layer function, e.g., PREOF (Packet Replication,
Elimination and Ordering Function).
Paragraph (version A):
As non-DetNet and DetNet IP packets are identical on the wire, from
data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior.  As
shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic
treatment within the domain.
Paragraph (version B):
As non-DetNet and DetNet IP packets are identical on the wire, from
data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior.  As
shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the flow receives the proper
traffic treatment within the domain.
Paragraph (version A):
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
provided using the standard differentiated services code point (DSCP)
field RFC2474 and related mechanisms.
Paragraph (version B):
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
provided using the standard differentiated services (DSCP) field
RFC2474 and related mechanisms.
Paragraph (version A):
Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a
future document.  From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
previously mentioned optional field, uniquely identifies a DetNet IP
flow.
Paragraph (version B):
Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a
future document.  From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
previously mentioned optional field (i.e., flow label), uniquely
identifies a DetNet IP flow.
Paragraph (version A):
Remarking packets associated with an incomplete reservation.
Remarking can be accomplished by changing the value of the DSCP,
or optional, field to a value that results in the packet no longer
matching any other reserved DetNet IP flow.
Paragraph (version B):
Remarking packets associated with an incomplete reservation.
Remarking can be accomplished by changing the value of the DSCP
field to a value that results in the packet no longer matching any
other reserved DetNet IP flow.
Paragraph (version A):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple, and an additional optional field defined in ip-flow-id.
The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows.  From a resource
allocation perspective, DetNet nodes must provide service to an
aggregate and not on a component flow basis.
Paragraph (version B):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple, and an additional optional field (i.e., flow label).
The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows.  From a resource
allocation perspective, DetNet nodes ought to provide service to an
aggregate rather than on a component flow basis.
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 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 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 to 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 it applies to future
mechanisms such as those that may be provided in YANG models I-
D.ietf-detnet-yang.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification based on header information identified in this
section.  Support for TCP, UDP and IPsec flows is defined.  Future
documents are expected to define support for other protocols.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification based on header information identified in this
section.  Support for TCP, UDP, ICMP and IPsec flows is defined.
Future documents are expected to define support for other protocols.
Paragraph (version B):
DetNet flow identification for ICMP is achieved based on the
protocol's header.  Note that ICMP type is not included in the flow
definition.
Paragraph (version A):
detnet-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):
detnet-ip-over-tsn.  Other mechanisms than the ones used in the TSN
case are outside the scope of this document.
Paragraph (version A):
If the DSCP field is to be used in flow identification.
Ignoring the DSCP field is optional.
Paragraph (version A):
When the DSCP field is used in flow identification, a list of
field values that may be used by a specific flow.
Paragraph (version B):
Whether or not the DSCP field is used in flow identification.
Use of the DSCP field for flow identification is optional.
Paragraph (version B):
If the DSCP field is used to identify a flow, then the flow
identification information (for that flow) includes a list of
DSCPs used by that flow.