Draft: draft-ietf-detnet-mpls

Commentary: ip :  references ip : untab and whitespace cleanup to keep xml2rfc happy ip : revise aggregation section , add alloc to sec 6 
 Let 's discuss these comments
Paragraph (version A):
The resource control and management aspects of aggregation (including
the queuing/shaping/ policing implications) will be covered in other
documents.
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 control in the data, management and control
planes.  The DetNet data plane allows for the aggregation of DetNet
flows, to improved scaling.  There are two methods of supporting flow
aggregation covered in this section.
Paragraph (version B):
The resource control and management aspects of aggregation (including
the configuration of queuing, shaping, and policing) is the
responsibility of the DetNet controller plane and will be covered in
other documents.  It is also the responsibility of the controller
plane to ensure that consistent aggregation methods are used.
Paragraph (version A):
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see RFC4206.  H-LSPs are
typically used to aggregate control and resources, they may also be
used to provide OAM or protection for the aggregated LSPs.  Arbitrary
levels of aggregation naturally falls out of the definition for
hierarchy and the MPLS label stack RFC3032.  DetNet nodes which
support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP.  Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will need to
ensure that traffic from aggregated LSPs are placed (shaped/policed/
enqueued) onto the H-LSPs in a fashion that ensures the required
DetNet service is preserved.
Paragraph (version A):
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.  Controller 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 B):
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see RFC4206.  H-LSPs are
typically used to aggregate control and resources, they may also be
used to provide OAM or protection for the aggregated LSPs.  Arbitrary
levels of aggregation naturally falls out of the definition for
hierarchy and the MPLS label stack RFC3032.  DetNet nodes which
support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP.  Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will need to
ensure that component LSPs and H-LSPs receive the traffic treatement
required to ensure 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 the new service definitions
mentioned above or in separate future documents.  Controller 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):
Another approach would be not to include a d-CW for the aggregated
flow.  This would be functionally similar to aggregation at the
forwarding sub-layer using H-LSPs, but would confine knowledge of the
aggregation to the DetNet layer.  Such an approach shares the
disadvantage that PREOF operations would not be possible.  OAM
operation in this mode is for further study.
Paragraph (version B):
As in the previous section, nodes supporting this type of
aggregetation will need to ensure that component and aggregated flows
receive the traffic treatement required to ensure the required DetNet
service is preserved.  Also, it is the controller plane's
responsibility to to ensure that the service required on the
aggregate flow are properly provisioned.
Paragraph (version A):
MPLS Service Label and d-CW labels at a DetNet end system.
Paragraph (version A):
MPLS Service Label and d-CW in the context of one or more MPLS
Forwarding Labels at any DetNet aware device along the path.
Paragraph (version A):
Any aggregate flow by one or more MPLS Forwarding Labels at any
DetNet aware device along the path.
Paragraph (version A):
Any other DetNet flow information for example IP Flow
Identification beyond the MPLS service label as specified in I-
D.ietf-detnet-ip at a DetNet aware device.
Paragraph (version B):
Each flow's service parameters and S-Label.
Paragraph (version B):
The PREOF functions to be supported for each S-Label.
Paragraph (version B):
The mapping of each S-Label to an F-Label stack.
Paragraph (version B):
S-Labels to A-Label mappings.
Paragraph (version B):
A-Label values and service parameters.
Paragraph (version B):
Each DetNet F-Label value and associated traffic parameters.
Paragraph (version B):
F-Label to H-LSP/Label mappings.
Paragraph (version B):
H-Label values and service parameters.
Paragraph (version B):
Outgoing interface, next hop, and sub-network parameters on a
technology specific basis.
Paragraph (version A):
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data.  No
DetNet specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in the I-D.ietf-detnet-framework.
Paragraph (version B):
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data.  No
DetNet specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using
an IP data plane.  From a data plane perspective, an end-to-end IP
model is followed.  As mentioned above, existing IP and higher layer
protocol header information is used to support flow identification
and DetNet service delivery.  Common data plane procedures and
control information for all DetNet data planes can be found in the I-
D.ietf-detnet-framework.
Paragraph (version B):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using
an IP data plane.  From a data plane perspective, an end-to-end IP
model is followed.  As mentioned above, existing IP and higher layer
protocol header information is used to support flow identification
and DetNet service delivery.  Common data plane procedures and
control information for all DetNet data planes can be found in the I-
D.ietf-detnet-data-plane-framework.
Paragraph (version A):
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document.  TSN over MPLS is
discribed in I-D.ietf-detnet-tsn-over-mpls.
Paragraph (version B):
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document.  TSN over MPLS is
discribed in I-D.ietf-detnet-tsn-vpn-over-mpls.
Paragraph (version A):
sec_dt_dp introduces the use of the IP "6-tuple" for flow
identification, and QoS goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation. ip-flow-id contains
detailed DetNet IP flow identification procedures.  Flow
identification plays an important role for the DetNet controller
plane.
Paragraph (version A):
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 A):
The use of prefixes, wildcards, bitmasks, and port ranges allows a
DetNet node to aggregate DetNet flows.  This aggregation can take
place within a single node, when that node maintains state about both
the aggregated and component flows.  It can also take place between
nodes, where one node maintains state about only flow aggregates
while the other node maintains state on all or a portion of the
component flows.  In either case, the management or control function
that provisions the aggregate flows must ensure that adequate
resources are allocated and configured to provide combined service
requirements of the component flows.  As DetNet is concerned about
latency and jitter, more than just bandwidth needs to be considered.
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.  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 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 flows are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
Paragraph (version A):
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 B):
As described in I-D.ietf-detnet-data-plane-framework, the ability to
aggregate individual flows, and their associated resource control,
into a larger aggregate is an important technique for improving
scaling by reducing the state per hop.  DetNet IP data plane
aggregation can take place within a single node, when that node
maintains state about both the aggregated and component flows.  It
can also take place between nodes, where one node maintains state
about only flow aggregates while the other node maintains state on
all or a portion of the component flows.  In either case, the
management or control function that provisions the aggregate flows
must ensure that adequate resources are allocated and configured to
provide combined service requirements of the component flows.  As
DetNet is concerned about latency and jitter, more than just
bandwidth needs to be considered.
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 fields defined in ip-flow-id.  The use of prefixes,
wildcards, bitmasks, and value ranges allows a DetNet node to
identify aggregate DetNet flows.  From a resource allocation
perspective, DetNet nodes must provide service to a aggregate and not
on a component flow basis.
Paragraph (version B):
It is the responsibility of the DetNet controller plane to properly
provision the use of these aggregation mechanisms.  This includes
ensuring that aggregated flows have compatible e.g., the same or very
similar QoS and/or CoS characteristics, see QoS.  It also includes
ensuring that per component-flow service requirements are satisfied
by the aggregate, see ip-svc.
Paragraph (version A):
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):
D.ietf-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 A):
Information identifying a DetNet flow is ordered and implementations
use the first match.  This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service
for all other flows with that same UDP Destination Port value.
Paragraph (version B):
Information identifying a DetNet flow is ordered and implementations
use the first match.  This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service
for the aggregate of all other flows with that same UDP Destination
Port value.