Draft: draft-ietf-detnet-mpls

Commentary: Some more cleanup for next submission .
Paragraph (version A):
The DetNet MPLS data plane representation is illustrated in
dn_mpls_dp_approach.  The service sub-layer includes a DetNet control
word (d-CW) and a identifying service label (S-Label).  The DetNet
control word (d-CW) conforms to the Generic PW MPLS Control Word
(PWMCW) defined in RFC4385.
Paragraph (version B):
The DetNet MPLS data plane representation is illustrated in
dn_mpls_dp_approach.  The service sub-layer includes a DetNet control
word (d-CW) and a identifying service label (S-Label).  The DetNet
control word (d-CW) conforms to the Generic PW MPLS Control Word
(PWMCW) defined in RFC4385.  An aggregation label (A-Label) is a
special case of S-Label used for aggregation.
Paragraph (version A):
The S-Label value MUST be provisioned per app-flow via configuration,
e.g., via the controller plane described in I-D.ietf-detnet-data-
plane-framework.  Note that S-Labels provide app-flow identification
at the downstream DetNet service sub-layer receiver, not the sender.
As such, S-Labels MUST be allocated by the entity that controls the
service sub-layer receiving node's label space, and MAY be allocated
from the platform label space RFC3031.
Paragraph (version B):
The S-Label value MUST be provisioned per app-flow via configuration,
e.g., via the controller plane described in I-D.ietf-detnet-data-
plane-framework.  Note that S-Labels provide app-flow identification
at the downstream DetNet service sub-layer receiver, not the sender.
As such, S-Labels MUST be allocated by the entity that controls the
service sub-layer receiving node's label space, and MAY be allocated
from the platform label space RFC3031.  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):
When sending a DetNet flow, Zero or more F-Labels MAY be added on top
of an S-Label by the node pushing an S-Label.  The F-Labels to be
pushed when sending a particular app-flow MUST be provisioned per
app-flow via configuration, e.g., via the controller plane discussed
in I-D.ietf-detnet-data-plane-framework.  To allow for the omission
of F-Labels, an implementation SHOULD also allow an outgoing
interface to be provisioned.
Paragraph (version B):
When sending a DetNet flow, Zero or more F-Labels MAY be added on top
of an S-Label by the node pushing an S-Label.  The F-Labels to be
pushed when sending a particular app-flow MUST be provisioned per
app-flow via configuration, e.g., via the controller plane discussed
in I-D.ietf-detnet-data-plane-framework.  F-Labels can also provide
context for an S-Label.  To allow for the omission of F-Labels, an
implementation SHOULD also allow an outgoing interface to be
provisioned.
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 individual LSPs and H-LSPs receive the traffic treatement
required to ensure the required DetNet service is preserved.
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 individual LSPs and H-LSPs receive the traffic treatment
required to ensure the required DetNet service is preserved.
Paragraph (version A):
As in the previous section, nodes supporting this type of
aggregetation will need to ensure that individual 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 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 to
ensure that the service required on the aggregate flow are properly
provisioned.
Paragraph (version A):
A DetNet Relay node operates in the DetNet forwarding sub-layer .
For DetNet using MPLS this processing is performed on the F-Label.
This processing is done within an extended forwarder function.
Whether an ingress DetNet member flow receives DetNet specific
processing depends on how the forwarding is programmed.  Some relay
nodes may be DetNet service aware, while others may be unmodified
LSRs that only understand how to swicth MPLS-TE LSPs.
Paragraph (version B):
A DetNet Relay node operates in the DetNet forwarding sub-layer .
For DetNet using MPLS this processing is performed on the F-Label.
This processing is done within an extended forwarder function.
Whether an ingress DetNet member flow receives DetNet specific
processing depends on how the forwarding is programmed.  Some relay
nodes may be DetNet service aware, while others may be unmodified
LSRs that only understand how to switch MPLS-TE LSPs.
Paragraph (version A):
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.  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 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):
Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process, or in a centralized or
distributed manner, is out of scope of this document.