Draft: draft-ietf-detnet-mpls

Commentary: reference ( change framework to normative ) editorial ( zero as a valid sequence number topic )
Paragraph (version A):
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in
fig_detnet_cw MUST be present in all DetNet packets containing app-
flow data.  This format of the d-CW was created in order (1) to allow
larger S/N space to avoid S/N rollover frequency in some applications
and (2) to allow non-skip zero S/N what simplifies implementation.
Paragraph (version B):
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in
fig_detnet_cw MUST be present in all DetNet packets containing app-
flow data.  This format of the d-CW was created in order (1) to allow
larger S/N space to avoid S/N rollover frequency in some applications
and (2) to allow sequence numbering systems that include the value
zero as a valid sequence number, which simplifies implementation.
Paragraph (version A):
When the sequence number field length is 16 or 28 bits for a flow,
the sequence number MUST be incremented by one for each new app-flow
packet sent.  When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0).  The values carried in this field can wrap
and it is important to note that zero (0) is a valid field value.
For example, were the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1, where zero (0) is an ordinary sequence
number.
Paragraph (version B):
When the sequence number field length is 16 or 28 bits for a flow,
the sequence number MUST be incremented by one for each new app-flow
packet sent.  When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0).  The values carried in this field can wrap
and it is important to note that zero (0) is a valid field value.
For example, where the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1, where zero (0) is an ordinary sequence
number.
Paragraph (version A):
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) RFC6790
MAY be carried below the S-Label in the label stack in networks where
DetNet flows would otherwise received ECMP treatment.  When ELs are
used, the same EL value SHOULD be used for all of the packets sent
using a specific S-Label to force the flow to follow the same path.
However, as outlines in I-D.ietf-detnet-data-plane-framework the use
of ECMP for DetNet flows is NOT RECOMMENDED.  ECMP MAY be used for
non-DetNet flows within a DetNet domain.
Paragraph (version B):
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) RFC6790
MAY be carried below the S-Label in the label stack in networks where
DetNet flows would otherwise received ECMP treatment.  When ELs are
used, the same EL value SHOULD be used for all of the packets sent
using a specific S-Label to force the flow to follow the same path.
However, as outlined in I-D.ietf-detnet-data-plane-framework the use
of ECMP for DetNet flows is NOT RECOMMENDED.  ECMP MAY be used for
non-DetNet flows within a DetNet domain.
Paragraph (version A):
F-Labels are supported the DetNet forwarding sub-layer.  F-Labels are
used to provide LSP-based connectivity between DetNet service sub-
layer processing nodes.
Paragraph (version B):
F-Labels support the DetNet forwarding sub-layer.  F-Labels are used
to provide LSP-based connectivity between DetNet service sub-layer
processing nodes.
Paragraph (version A):
Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label.  Each LSP MAY be provisioned with a
service parameters that dictates the specific traffic treatment to be
received by the traffic carried over that LSP.  Implementations of
this document MUST ensure that traffic carried over each LSP
represented by one or more F-Labels receives the traffic treatment
provisioned for that LSP.  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) that may be found
in implementations of RFC2205 (RSVP) and RSVP-TE RFC3209 and RFC3473.
Support can also be provided via an underlying network technology
such IEEE802.1 TSN I-D.ietf-detnet-mpls-over-tsn.  The specific
mechanisms selected 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):
Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label.  Each LSP MAY be provisioned with a
service parameter that dictates the specific traffic treatment to be
received by the traffic carried over that LSP.  Implementations of
this document MUST ensure that traffic carried over each LSP
represented by one or more F-Labels receives the traffic treatment
provisioned for that LSP.  Typical mechanisms used to provide
different treatment to different flows includes the allocation of
system resources (such as queues and buffers) and provisioning of
related parameters (such as shaping, and policing) that may be found
in implementations of RFC2205 (RSVP) and RSVP-TE RFC3209 and RFC3473.
Support can also be provided via an underlying network technology
such IEEE802.1 TSN I-D.ietf-detnet-mpls-over-tsn.  The specific
mechanisms selected 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):
MUST ensure a CoS flow or service class does not impact the
service delivered to other flows.  This requirement is similar to
requirement for MPLS LSRs to that CoS LSPs do not impact the
resources allocated to TE LSPs, e.g., via RFC3473.
Paragraph (version B):
MUST ensure a CoS flow or service class does not impact the
service delivered to other flows.  This requirement is similar to
the requirement for MPLS LSRs that CoS LSPs do not impact the
resources allocated to TE LSPs, e.g., via RFC3473.
Paragraph (version A):
As in the previous section, nodes supporting this type of aggregation
will need to ensure that individual and aggregated flows receive the
traffic treatment 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 B):
As in the previous section, nodes supporting this type of aggregation
will need to ensure that individual and aggregated flows receive the
traffic treatment required to ensure the required DetNet service is
preserved.  Also, it is the controller plane's responsibility to
ensure that the service required on the aggregate flow are properly
provisioned.
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
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 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 may be 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):
A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE)
RFC3209 and RFC3473.  TE LSPs can also support explicit routes (path
pinning).  Current service definitions for packet TE LSPs can be
found in "Specification of the Controlled Load Quality of Service",
RFC2211, "Specification of Guaranteed Quality of Service", RFC2212,
and "Ethernet Traffic Parameters", RFC6003.  Additional service
definitions are expected in future documents to support the full
range of DetNet services.  In all cases, the existing label-based
marking mechanisms defined for TE-LSPs and even E-LSPs are use to
support the identification of flows requiring DetNet QoS.
Paragraph (version B):
A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can be provided by MPLS with Traffic Engineering (MPLS-TE)
RFC3209 and RFC3473.  TE LSPs can also support explicit routes (path
pinning).  Current service definitions for packet TE LSPs can be
found in "Specification of the Controlled Load Quality of Service",
RFC2211, "Specification of Guaranteed Quality of Service", RFC2212,
and "Ethernet Traffic Parameters", RFC6003.  Additional service
definitions are expected in future documents to support the full
range of DetNet services.  In all cases, the existing label-based
marking mechanisms defined for TE-LSPs and even E-LSPs are use to
support the identification of flows requiring DetNet QoS.
Paragraph (version A):
The outgoing S-Label for each of the service's outgoing DetNet
(member) flow.
Paragraph (version B):
The outgoing S-Label for each of the service's outgoing DetNet
(member) flows.
Paragraph (version A):
On the receiving node, the A-Label provides the forwarding context of
an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated.  The
related addition configuration that may be provided discussed
elsewhere in this section.
Paragraph (version B):
On the receiving node, the A-Label provides the forwarding context of
an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated.  The
related additional configuration that may be provided is discussed
elsewhere in this section.
Paragraph (version A):
It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements.  This applies for aggregated and
individual flows.
Paragraph (version B):
It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow-specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements.  This applies for aggregated and
individual flows.