Draft: draft-ietf-detnet-ip-over-mpls

Commentary: resolve his comments per Oct 14 call .
Paragraph (version A):
Per I-D.ietf-detnet-mpls, the DetNet MPLS data plane uses a single
S-Label to support a single app flow.  Section 7.1.  DetNet IP Flow
Identification Procedures in I-D.ietf-detnet-ip states that a single
DetNet flow is identified based on IP, and next level protocol,
header information.  Section 7.4.  Aggregation Considerations in I-
D.ietf-detnet-ip defines that aggregation is supported through the
use of prefixes, wildcards, bitmasks, and port ranges.  Collectively,
this results in the fairly straight forward procedures defined in
this section.
Paragraph (version B):
Per I-D.ietf-detnet-mpls, the DetNet MPLS data plane uses a single
S-Label to support a single app flow.  Section 7.1.  DetNet IP Flow
Identification Procedures in I-D.ietf-detnet-ip states that a single
DetNet flow is identified based on IP, and next level protocol,
header information.  Section 7.4.  Aggregation Considerations in I-
D.ietf-detnet-ip defines that aggregation is supported through the
use of prefixes, wildcards, lists, and port ranges.  Collectively,
this results in the fairly straight forward procedures defined in
this section.
Paragraph (version B):
Explicit Congestion Notification.
Paragraph (version A):
The DetNet IP data plane uses "6-tuple" based flow identification,
where 6-tuple refers to information carried in IP and higher layer
protocol headers.  The 6-tuple referred to in this document is the
same as that defined in RFC3290.  Specifically 6-tuple is
(destination address, source address, IP protocol, source port,
destination port, and differentiated services (DiffServ) code point
(DSCP).  General background on the use of IP headers, and 5-tuples,
to identify flows and support Quality of Service (QoS) can be found
in RFC3670.  RFC7657 also provides useful background on the delivery
of DiffServ and "tuple" based flow identification.  Referring to a
6-tuple allows DetNet nodes to forward packets with the 6-tuple as is
or remap the DSCP where required by the DetNet service.
Paragraph (version A):
DetNet flow aggregation may be enabled via the use of wildcards,
masks, prefixes and ranges.  IP tunnels may also be used to support
flow aggregation.  In these cases, it is expected that DetNet aware
intermediate nodes will provide DetNet service assurance on the
aggregate through resource allocation and congestion control
mechanisms.
Paragraph (version B):
The DetNet IP data plane primarily uses "6-tuple" based flow
identification, where 6-tuple refers to information carried in IP and
higher layer protocol headers.  The 6-tuple referred to in this
document is the same as that defined in RFC3290.  Specifically
6-tuple is (destination address, source address, IP protocol, source
port, destination port, and differentiated services (DiffServ) code
point (DSCP).  General background on the use of IP headers, and
5-tuples, to identify flows and support Quality of Service (QoS) can
be found in RFC3670.  RFC7657 also provides useful background on the
delivery of DiffServ and "tuple" based flow identification.
Paragraph (version B):
The DetNet IP data plane also allows for optional matching on two
additional data fields.  The optional fields are the ECN Field, as in
RFC3168, and the IPv6 flow label field, as defined in RFC8200.
Paragraph (version B):
Generally the fields used in flow identification are forward
unmodified but modification is allowed, for example to a DSCP value,
when required by the DetNet service.
Paragraph (version B):
DetNet flow aggregation may be enabled via the use of wildcards,
masks, lists, prefixes and ranges.  IP tunnels may also be used to
support flow aggregation.  In these cases, it is expected that DetNet
aware intermediate nodes will provide DetNet service assurance on the
aggregate through resource allocation and congestion control
mechanisms.
Paragraph (version B):
In order to maximize reuse of 5-tuple based mechanisms, e.g,
traceroute, DetNet aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple.
Paragraph (version B):
Note that not mixing DetNet and non-DetNet traffic within a single
5-tuple, as described above, enables simpler 5-tuple filters to be
reused at the edges of a DetNet network to prevent non-congestion
responsive DetNet traffic from escaping the DetNet domain.
Paragraph (version A):
Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a
future document.  From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code,
uniquely identifies a DetNet service flow.
Paragraph (version B):
Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a
future document.  From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
previously mentioned two optional fields, uniquely identifies a
DetNet service flow.
Paragraph (version B):
While path selection algorithms and mechanisms are out of scope of
the DetNet data plane definition, it is important to highlight the
implications of DetNet IP flow identification on path selection and
next hops.  As mentioned above, the DetNet IP data plane identifies
flows using "6-tuple" header information as well as two additional
optional header fields.  DetNet generally allows for both flow-
specific traffic treatment and flow-specific next-hops.
Paragraph (version B):
In non-DetNet IP forwarding, it is generally assumed that the same
series of next hops, i.e., the same path, will be used for a
particular 5-tuple or, in some cases, e.g., RFC5120, for a particular
6-tuple.  Using different next hops for different 5-tuples does not
take any special consideration for DetNet aware applications.
Paragraph (version B):
Care should be taken when using different next hops for the same
5-tuple.  As discussed in RFC7657, unexpected behavior can occur when
a single 5-tuple application flow experience reordering due to being
split across multiple next hops.  Understanding of the application
and transport protocol impact of using different next hops for the
same 6-tuple is required.  Again, this impacts path selection for
DetNet flows and this document only indirectly.
Paragraph (version A):
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):
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, or two additional optional fields defined in ip-flow-id.
The use of prefixes, wildcards, lists, 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 A):
These fields are used to support Differentiated Services RFC2474 and
Explicit Congestion Notification RFC3168.  Implementations of this
document MUST support DetNet flow identification based on the IPv4
Type of Service field when processing IPv4 packets, and the IPv6
Traffic Class Field when processing IPv6 packets.  Implementations
MUST support bitmask based matching, where bits set to one (1) in the
bitmask indicate which subset of the bits in the field are to be used
in determining a match.  Note that all bits set to zero (0) value as
a bitmask effectively means that these fields are ignored.
Paragraph (version B):
These fields are used to support Differentiated Services RFC2474 and
Explicit Congestion Notification RFC3168.  Implementations of this
document MUST support DetNet flow identification based on the IPv4
Type of Service field when processing IPv4 packets, and the IPv6
Traffic Class Field when processing IPv6 packets.  Implementations
MUST support list based matching of DSCP values, where the list is
composed of possible field values that are to be considered when
identifying a specific DetNet flow.  Implementations SHOULD allow for
this field to be ignored for a specific DetNet flow.
Paragraph (version B):
Implementations of this document MUST allow the ECN field to be
ignored as part of DetNet flow identification.  Additionally,
implementations SHOULD support identification of DetNet flows based
on the value carried in the ECN field.  When this field is used to
identify a specific DetNet flow, implementations MUST support a list
of ECN values that match a specific slow.
Paragraph (version A):
IPv4 Type of Service and IPv6 Traffic Class Fields.
Paragraph (version A):
IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
zero (0) effectively means that theses fields are ignored.
Paragraph (version B):
If the DSCP field is to be used in flow identification.
Ignoring the DSCP filed is optional.
Paragraph (version B):
When the DSCP field is used in flow identification, a list of
field values that may be used by a specific flow.
Paragraph (version B):
If the ECN field is to be used in flow identification.
Matching based on ECN filed values is optional.
Paragraph (version B):
When ECN field is used in flow identification, a list of field
values that may be used by a specific flow.