Change:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).

Discussion:
DetNet Data Plane: MPLS <del> draft-ietf-detnet-mpls-09 </del> <ins> draft-ietf-detnet-mpls-10 </ins> Abstract

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 <del> F-Label(s). </del> <ins> F-Label(s).  In some PREOF topologies, the node performing replication will be sending to multiple nodes performing PEF or POF, and may need to send different S-Label values for the different member flows for the same DetNet service. </ins> An S-Label will normally be at the bottom of the label stack once the last F-Label is removed, immediately preceding the d-CW.  To support

e.g., via the controller plane described in I-D.ietf-detnet-data- plane-framework.  When replication is configure, the same app-flow data will be sent over multiple outgoing DetNet member flows using <del> forwarding sub-layer LSPs.  The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. </del> <ins> forwarding sub-layer LSPs.  An S-Label value MUST be configured per outgoing member flow.  The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. </ins> 4.2.2.2.

When sending a DetNet flow, zero or more F-Labels MAY be pushed on top of an S-Label by the node pushing an S-Label.  The F-Label(s) to be pushed when sending a particular DetNet service MUST be <del> provisioned per DetNet service via configuration, e.g., via the </del> <ins> provisioned per outgoing S-Label via configuration, e.g., via the </ins> controller plane discussed in I-D.ietf-detnet-data-plane-framework. F-Label(s) can also provide context for an S-Label.  To allow for the omission of F-Label(s), an implementation SHOULD also allow an <del> outgoing interface to be configured. </del> <ins> outgoing interface to be configured per S-Label. </ins> <del> When PRF is supported, the same app-flow data will be sent over </del> <ins> Note, when PRF is supported, the same app-flow data will be sent over </ins> multiple outgoing DetNet member flows using forwarding sub-layer <del> LSPs.  To support PRF an implementation MUST support the setting of different sets of F-Labels per DetNet member flow.  To allow for the omission of F-Labels, an implementation SHOULD also allow multiple outgoing interfaces to be provisioned. </del> <ins> LSPs.  This means that implementation may be sending different sets of F-Labels per DetNet member flow, each with a different S-Label. </ins> When a single set of F-Labels is provisioned for a particular outgoing S-Label, that set of F-labels MUST be pushed after the

When multiple sets of outgoing F-Labels or interfaces are provisioned for a particular DetNet service, a copy of the outgoing packet, <del> including the pushed S-Label, MUST be made per F-label set and outgoing interface.  Each set of provisioned F-Labels are then pushed onto a copy of the packet.  Each copy is then forwarded as described below in f-labels-all. </del> <ins> including the pushed member flow-specific S-Label, MUST be made per F-label set and outgoing interface.  Each set of provisioned F-Labels are then pushed onto a copy of the packet.  Each copy is then forwarded as described below in f-labels-all. </ins> As described in the previous section, when receiving a DetNet MPLS flow, an implementation identifies the DetNet service associated with

values included 0, 16 and 28 bits. 0 bits cannot be used when PEF or POF is configured for the service. <del> The outgoing S-Label for the service. </del> If PRF is to be provided for the service. <ins> The outgoing S-Label for each of the service's outgoing DetNet (member) flow. </ins> The forwarding sub-layer information associated with the output of the service sub-layer.  Note that when the PRF function is provisioned, this information is per DetNet member flow.