Draft: draft-ietf-detnet-data-plane-framework

Commentary: Hi Did a pass through the Framework . Clean up some text . There are still some identified areas in the document where it calls for more detail . Also there is a open reference . 
 reviewed in jun 24 call
Paragraph (version A):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  An example of
this is Packet Replication, Elimination, and Ordering (PREOF)
function see PREOF.
Paragraph (version A):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method.  There may be more than approach
that is applicable to a given bearer network type.
Paragraph (version A):
How the data plane is constructed: The DetNet service sub-layer
provides its functions for the DetNet application flows by using
or applying existing standardized headers and/or encapsulations.
The Detnet forwarding sub-layer may provide capabilities
leveraging that same header or encapsulation technology e.g.
dn_svcs or it may be achieved by other standardized technologies
e.g.  dn_svc_encaps.
Paragraph (version B):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  An example of
this is Packet Replication, Elimination, and Ordering (PREOF)
functions see PREOF.
Paragraph (version B):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method.  There may be more than one
approach that is applicable to a given bearer network type.
Paragraph (version B):
Data plane construction: The DetNet service sub-layer provides its
functions for the DetNet application flows by using or applying
existing standardized headers and/or encapsulations.  The Detnet
forwarding sub-layer may provide capabilities leveraging that same
header or encapsulation technology e.g. dn_svcs or it may be
achieved by other standardized technologies e.g.  dn_svc_encaps.
Paragraph (version A):
Explicit inclusion of metadata in an IP packet is also possible
through the inclusion of an MPLS label stack and the MPLS DetNet
Control Word using one of the methods for carrying MPLS over IP I-
D.mpls-over-udp-ip.  This is described in more detail in
subnet_considerations.
Paragraph (version A):
Implicit metadata can be included through the use of the network
programming paradigm I-D.spring-srv6-network-programming in which the
suffix of an IPv6 address is used to encode additional information
for use by the network of the receiving host.  Examples of such
information include the sequence number for use by the PREOF
function, or even all the essential information being included into
the DetNet over MPLS label stack (the DetNet Control Word and the
DetNet Service label).
Paragraph (version B):
Explicit inclusion of metadata in an IP packet is also possible
through the inclusion of an MPLS label stack and the MPLS DetNet
Control Word using one of the methods for carrying MPLS over IP I-
D.ietf-detnet-mpls-over-udp-ip.  This is described in more detail in
subnet_considerations.
Paragraph (version B):
Implicit metadata can be included through the use of the network
programming paradigm I-D.ietf-spring-srv6-network-programming in
which the suffix of an IPv6 address is used to encode additional
information for use by the network of the receiving host.  Examples
of such information include the sequence number for use by the PREOF
function, or even all the essential information being included into
the DetNet over MPLS label stack (the DetNet Control Word and the
DetNet Service label).
Paragraph (version A):
In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, this has been been provided through
the use of a shim layer also called a control word (CW) RFC4385.
Although such CWs are frequently 32 bits long, there is no
architectural constraint on its size of this structure, only the
requirement that it is fully understood by all parties operating on
it in the DetNet service sub-layer.  The operation of this method is
described in detail in I-D.ietf-detnet-mpls.
Paragraph (version A):
This section needs further work.
Paragraph (version B):
In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, a shim layer also called a control
word (CW) RFC4385 can be used.  Although such CWs are frequently 32
bits long, there is no architectural constraint on its size of this
structure, only the requirement that it is fully understood by all
parties operating on it in the DetNet service sub-layer.  The
operation of this method is described in detail in I-D.ietf-detnet-
mpls.
Paragraph (version A):
The above is of course illustrative of many network scenarios that
can be configured.  Between a pair of relay nodes there may be one or
more transit nodes that simply forward the DetNet traffic, but these
are omitted for clarity.
Paragraph (version B):
The above is of course illustrative of many network scenarios that
can be configured.
Paragraph (version A):
The DetNet data plane also allows for the aggregation of DetNet
flows, to improved scaling by reducing the state per hop.  How this
is done is data plane or control plane dependent.  When DetNet flows
are aggregated, transit nodes provide service to the aggregate and
not on a per-DetNet flow basis.  When aggregating DetNet flows the
flows should be compatible i.e. the same or very similar QoS and CoS
characteristics.  In this case, nodes performing aggregation will
ensure that per-flow service requirements are achieved.
Paragraph (version B):
The DetNet data plane also allows for the aggregation of DetNet
flows, to improved scaling by reducing the state per hop.  How this
is accomplished is data plane or control plane dependent.  When
DetNet flows are aggregated, transit nodes provide service to the
aggregate and not on a per-DetNet flow basis.  When aggregating
DetNet flows the flows should be compatible i.e. the same or very
similar QoS and CoS characteristics.  In this case, nodes performing
aggregation will ensure that per-flow service requirements are
achieved.
Paragraph (version A):
DetNet encapsulation is a data plane mechanism that can be used to
aggregate traffic.  Encapsulation can either be in the same service
type or in a different service type see dn_svc_encaps for examples.
When an encapsulation is used the choice of reserving a maximum
resource level and then tracking the services in the aggregated
service or adjusting the aggregated resources as the services are
added is implementation and technology specific.
Paragraph (version B):
DetNet encapsulation is a data plane mechanism that can be used to
aggregate traffic.  Encapsulation can either be in the same service
type or in a different service type see dn_svc_encaps for example.
When an encapsulation is used the choice of reserving a maximum
resource level and then tracking the services in the aggregated
service or adjusting the aggregated resources as the services are
added is implementation and technology specific.
Paragraph (version A):
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on application and its
preferences.  For example, a DetNet MPLS domain the DN functions use
the d-CWs, S-Labels and F-Labels to provide DetNet services.
However, an application may exchange further flow related parameters
(e.g., time-stamp), which are not provided by DN functions.
Paragraph (version B):
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on the application and its
preferences.  For example, a DetNet MPLS domain the DN functions use
the d-CWs, S-Labels and F-Labels to provide DetNet services.
However, an application may exchange further flow related parameters
(e.g., time-stamp), which are not provided by DN functions.
Paragraph (version A):
described in I-D.mpls-over-tsn.  UDP/IP represents the encapsulation
used on a DetNet IP PSN, as described in I-D.mpls-over-udp-ip.
Paragraph (version B):
described in I-D.ietf-detnet-mpls-over-tsn.  UDP/IP represents the
encapsulation used on a DetNet IP PSN, as described in I-D.ietf-
detnet-mpls-over-udp-ip.
Paragraph (version A):
In the case of MPLS Manage DetNet S-Label and F-Label allocation
and distribution, where the DetNet MPLS encapsulation is in use
see mpls_cp_considerations.
Paragraph (version A):
The ability to support DetNet flow aggregation.
Paragraph (version B):
In the case of MPLS, manage DetNet S-Label and F-Label allocation
and distribution, where the DetNet MPLS encapsulation is in use
see mpls_cp_considerations.
Paragraph (version B):
Support DetNet flow aggregation.
Paragraph (version A):
Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and
TSN, both of which aggregate multiple DetNet flows into a single new
DetNet flow.  It can also be grouping of IP flows that share 5-tuple
of 6-tuple attributes or flow identifiers at the DetNet sub-layer.
Paragraph (version B):
Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and
TSN, both of which aggregate multiple DetNet flows into a single new
DetNet flow.  It can also be grouping of IP flows that share 5-tuple
or 6-tuple attributes or flow identifiers at the DetNet sub-layer.
Paragraph (version A):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in I-D.mpls-over-tsn ) DetNet parameters can be maintained.
Further considerations and requirements for the DetNet Controller
Plane are discussed in control-management-requirements.
Paragraph (version B):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in I-D.ietf-detnet-mpls-over-tsn ) DetNet parameters can be
maintained.  Further considerations and requirements for the DetNet
Controller Plane are discussed in control-management-requirements.
Paragraph (version A):
Control and management mechanisms need to support bidirectional
flows, but the specification of such mechanisms are out of scope of
this document.  An example control plane solution for MPLS can be
found in .  Related control plan mechanisms have been defined in
RFC3473 , RFC6387 and RFC7551.
Paragraph (version B):
Control and management mechanisms need to support bidirectional
flows, but the specification of such mechanisms are out of scope of
this document.  An example control plane solution for MPLS can be
found in ???.  Related control plan mechanisms have been defined in
RFC3473 , RFC6387 and RFC7551.
Paragraph (version A):
sec_dt_dp discussed the use of the IP "6-tuple" for flow
identification, and goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation.  I-D.ietf-detnet-ip
contains detailed DetNet IP flow identification procedures.  Flow
identification will play an important role for the DetNet controller
plane.
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 I-D.ietf-detnet-ip , 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.  These requirements are included in control-
management-requirements.
Paragraph (version A):
This section covers MPLS data plane specific control plane
considerations.  This section needs generalizing.
Paragraph (version B):
sec_dt_dp discussed the use of the IP "6-tuple" for flow
identification, and goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation.  I-D.ietf-detnet-ip
contains detailed DetNet IP flow identification procedures.  Flow
identification plays an important role for the DetNet controller
plane.
Paragraph (version B):
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 I-D.ietf-detnet-ip , using a DSCP identified traffic class
or other field.  It is the responsibility of the DetNet controller
plane to be able to properly provision the use of these aggregation
mechanisms.  These requirements are included in control-management-
requirements.
Paragraph (version B):
This section covers MPLS data plane specific control plane
considerations.
Paragraph (version A):
S-Labels are expected to be allocated in the same manner as any other
service labels.  S-Labels uniquely identify a particular DetNet flow,
and are local to the node on which the label is allocated.  In the
DetNet service sub-layer the explicit route consists of the set of
Relay Nodes that the DetNet flow must traverse.  They can be used to
identify the DetNet flow that a packet belongs to as it traverses a
particular node in a DetNet domain.  Because labels are local to each
node rather than being a global identifier within a domain, they must
be advertised to their upstream DetNet service-aware peer nodes
(e.g., a DetNet MPLS End System or a DetNet Relay or Edge Node and
interpreted in the context of their received F-Label.
Paragraph (version B):
S-Labels are expected to be allocated in the same manner as any other
service labels.  S-Labels uniquely identify a particular DetNet flow,
and are local to the node on which the label is allocated.  In the
DetNet service sub-layer the explicit route consists of the set of
Relay Nodes that the DetNet flow must traverse.  S-Labels can be used
to identify the DetNet flow that a packet belongs to as it traverses
a particular node in a DetNet domain.  Because S-Labels are local to
each node rather than being a global identifier within a domain, they
must be advertised to their upstream DetNet service-aware peer nodes
(e.g., a DetNet MPLS End System or a DetNet Relay or Edge Node and
interpreted in the context of their received F-Label.
Paragraph (version A):
As discussed in sec_dt_dp, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is MPLS.  F-Labels can also
provide context for an S-Label.  In the DetNet Forwarding (MPLS) sub-
layer the explicit route consists of the set of DetNet nodes which
are LSRs, links, and possibly link bundle members and queues that the
DetNet packets of a flow must traverse between nodes in the DetNet
service sub-layer (i.e. between a specific Edge Node and the next hop
Relay Node, between specific Relay Nodes, and between a specific
Relay node and the egress Edge Node.  Resource allocation
corresponding to the set of Services supported over the forwarding
sub-layer, which may or may not include aggregation, is required at
this sub-layer.  Explicit routes are used to ensure that packets are
routed through the resources that have been reserved for them, and
hence provide the DetNet application with the required service.
Multiple F-Labels may be pushed after an S-Label and there is no
requirement for all F-Labels to be controlled via the same controller
mechanisms.  For example in EVPN, some labels are distributed using
BGP while others are distributed using LDP or RSVP.
Paragraph (version B):
As discussed in sec_dt_dp, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is MPLS.  F-Labels can also
provide context for an S-Label.  In the DetNet Forwarding (MPLS) sub-
layer the explicit route consists of the set of DetNet nodes which
are LSRs, links, and possibly link bundle members and queues that the
DetNet packets flow must traverse between nodes in the DetNet service
sub-layer (i.e. between a specific Edge Node and the next hop Relay
Node, between specific Relay Nodes, and between a specific Relay node
and the egress Edge Node.  Resource allocation corresponding to the
set of Services supported over the forwarding sub-layer, which may or
may not include aggregation, is required at this sub-layer.  Explicit
routes are used to ensure that packets are routed through the
resources that have been reserved for them, and hence provide the
DetNet application with the required service.  Multiple F-Labels may
be pushed after an S-Label and there is no requirement for all
F-Labels to be controlled via the same controller mechanisms.  For
example in EVPN, some labels are distributed using BGP while others
are distributed using LDP or RSVP.
Paragraph (version A):
The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document.  That said,
it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support.  There are be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery RFC4872
and GMPLS segment recovery RFC4873.
Paragraph (version B):
The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document.  That said,
it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support.  There may be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery RFC4872
and GMPLS segment recovery RFC4873.