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

Commentary: IP over MPLS changes to be reviewed .
Paragraph (version A):
An example use of DetNet IP over DetNet MPLS follows below.
Paragraph (version A):
fig_dn_ip_mpls_detnet illustrates DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled IP networks, operating over a DetNet
aware MPLS network.  In this figure, Relay nodes sit at the boundary
of the MPLS domain since the non-MPLS domain is DetNet aware.  This
figure is very similar to the DetNet MPLS Network figure in I-D.ietf-
detnet-mpls.  The primary difference is that the Relay nodes are at
the edges of the MPLS domain and therefore function as T-PEs, and
that service sub-layer functions are not provided over the DetNet IP
network.  The transit node functions show above are identical to
those described in I-D.ietf-detnet-mpls.
Paragraph (version B):
An example use of DetNet IP over DetNet MPLS is presented here.
Paragraph (version B):
fig_ip_detnet illustrated DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled IP networks, operating over a DetNet
aware MPLS network.  iUsing this figure we can have a case where the
Relay nodes act as T-PEs and sit at the boundary of the MPLS domain
since the non-MPLS domain is DetNet aware.  This case is very similar
to the DetNet MPLS Network figure 2 in I-D.ietf-detnet-mpls.  However
in I-D.ietf-detnet-mpls figure 2 the T-PEs are located at the end
syetem and MPLS spans the whole DetNet service.  The primary
difference in this document is that the Relay nodes are at the edges
of the MPLS domain and therefore function as T-PEs, and that iMPLS
service sub-layer functions are not provided over the DetNet IP
network.  The transit node functions show above are identical to
those described in I-D.ietf-detnet-mpls.
Paragraph (version A):
fig_ip_mpls_detnet illustrates non-DetNet enabled End Systems
(hosts), connected to DetNet (DN) enabled MPLS network.  It differs
from fig_dn_ip_mpls_detnet in that the hosts and edge IP networks are
not DetNet aware.  In this case, edge nodes sit at the boundary of
the MPLS domain since it is also a DetNet domain boundary.  The edge
nodes provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows.  While the node types differ, there is essentially no
difference in data plane processing between relay and edges.  There
are likely to be differences in controller plane operation,
particularly when distributed control plane protocols are used.
Paragraph (version A):
fig_pw_detnet2 illustrates how it is still possible to provided
DetNet service protection for non-DetNet aware end systems.  This
figures is basically the same as fig_ip_pw_detnet, with the exception
that CE1 and CE2 are non-DetNet aware end systems and E1 and E3 are
edge nodes that replace the relay nodes R1 and R3.
Paragraph (version B):
fig_ip_detnet illustrates DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled MPLS network.  A similar situation
occurs when end systems are are not DetNet aware.  In this case, edge
nodes sit at the boundary of the MPLS domain since it is also a
DetNet domain boundary.  The edge nodes provide DetNet service
proxies for the end applications by initiating and terminating DetNet
service for the application's IP flows.  While the node types differ,
there is essentially no difference in data plane processing between
relay and edges.  There are likely to be differences in controller
plane operation, particularly when distributed control plane
protocols are used.
Paragraph (version B):
It is still possible to provided DetNet service protection for non-
DetNet aware end systems.  case is basically the same as
fig_ip_pw_detnet, with the exception that CE1 and CE2 are non-DetNet
aware end systems and R1 and R3 become edge nodes.
Paragraph (version A):
As shown in fig_ip_mpls_detnet, DetNet relay nodes are responsible
for the mapping of a DetNet flow, at the service sub-layer, from the
IP to MPLS DetNet data planes and back again.  Their related DetNet
IP over DetNet MPLS data plane operation is comprised of two sets of
procedures: the mapping of flow identifiers; and ensuring proper
traffic treatment.
Paragraph (version B):
As shown in fig_ip_pw_detnet, DetNet relay nodes are responsible for
the mapping of a DetNet flow, at the service sub-layer, from the IP
to MPLS DetNet data planes and back again.  Their related DetNet IP
over DetNet MPLS data plane operation is comprised of two sets of
procedures: the mapping of flow identifiers; and ensuring proper
traffic treatment.
Paragraph (version B):
Mapping of IP to the MPLS Detnet is similar for IP Detnet flows and
IP flows.  The six-tuple of IP is mapped to the S-Label in both
cases.  The various fields may be mapped or ignored when going from
IP to MPLS.
Paragraph (version A):
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP
specific security considerations are described in I-D.ietf-detnet-
mpls and I-D.ietf-detnet-ip.  This draft does not have additional
security considerations.
Paragraph (version B):
This draft does not have additional security considerations.
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in I-D.ietf-detnet-architecture.  MPLS and IP specific
considerations are described in I-D.ietf-detnet-mpls and I-D.ietf-
detnet-ip.
Paragraph (version B):
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
Paragraph (version B):
The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network.  Application flows can be protected
through whatever means is provided by the underlying technology.  For
example, encryption may be used, such as that provided by IPSec
RFC4301 for IP flows and/or by an underlying sub-net using MACSec
IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows.
Paragraph (version B):
From a data plane perspective this document does not add or modify
any header information.
Paragraph (version B):
At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to
controller planes that do not include per-flow identification).  This
is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable
technology for any given use case.
Paragraph (version B):
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks.  To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain.  To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of Man-In-The-
Middle attacks, for example through use of authentication and
authorization of devices within the DetNet domain.