DetNet Data Plane: IP over MPLS

Note: This ballot was opened for revision 07 and is now closed.

(Deborah Brungard) Yes

(Alissa Cooper) No Objection

Roman Danyliw No Objection

Comment (2020-09-09 for -07)
(Identical comments as draft-ietf-detnet-mpls – if needed, we can chat about them only once)

** Section 6.  Per “Application flows can be protected through whatever means are provided by the underlying technology”, what is the scope of “underlying technology”, is that an application concern?  Or a DetNet data or control plan concern?  The text isn’t clear on who’s responsibility it is to provide these services (IPSec or MacSec), or what assumptions the application can make?  IMO, the clearer statement to make is that MPLS doesn’t provide any native security services to account for confidentiality and integrity.

** Section 6.  Per “From a data plane perspective this document does not add or modify any header information.”, to be clear, does this text mean “_application_ header information”?  I’d recommend being clear.

** Section 6. Please s/for the mitigation of Man-In-The-Middle attackers/for the mitigation of on-path attackers/

** Note the DISCUSS for draft-ietf-detnet-mpls.  Whatever the resolution on that text would apply here too.  Due to the overlap in authors on both documents, I’m adding the marker for that feedback here as a comment.

Martin Duke No Objection

Comment (2020-09-01 for -07)
In the response to the tsvart review, you said you would add some text here about multipath. I was not able to find any such reference.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-09-17 for -08)
Updating to demote my point form Discuss to Comment.
I am still interested in continuing the conversation, which is basically the one
going on in Alvaro's ballot thread, so let's continue it there.

Former Discuss section:

I do see the response to Alvaro's ballot position but I'm still not sure that
I understand what specifically requires this document to be on the standards-track.
Yes, there are differences between IP-over-MPLS and IP-over-DetNet-MPLS, but
(e.g.) how much of the DetNet-specific handling is just "when you send the traffic
onwards you need to ensure the quality of service" which in this scenario means
translating the DetNet IP needs into the DetNet MPLS configuration?  In other words,
a lot of this seems to be just giving information about how to fulfill the existing
requirements from (e.g.) draft-ietf-detnet-ip, so I am not sure that I understand what
the truly new protocol pieces and/or requirements are.

Original Comment section:

Section 4.1

   Figure 1 illustrates DetNet enabled End Systems connected to DetNet
   (DN) enabled MPLS network.  A similar situation occurs when end

nit: missing article ("a DetNet [...] network").  Also, this paragraph
appears after Figure 2, so the reference back to Figure 1 is perhaps
unusual (albeit, as far as I can tell, correct).

Section 4.2

   In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP
   data plane.  "IP" and "NProto" indicate the fields described in
   Section 5.1.1.  (IP Header Information) and Section 5.1.2.  (Other

It seems like the document production pipeline is introducing spurious
periods after the section numbers, which make this a bit confusing (and
some later text, too).

Section 5.1

   flow.  The provisioning of the mapping of DetNet IP flows to DetNet
   MPLS flows MUST be supported via configuration, e.g., via the
   controller plane.

I'm not sure I understand why this requirement is only for "support" --
how else would it be done?

   A DetNet relay node (egress T-PE) MAY be provisioned to handle
   packets received via the DetNet MPLS data plane as DetNet IP flows.
   A single incoming DetNet MPLS flow MAY be treated as a single DetNet
   IP flow, without examination of IP headers.  Alternatively, packets

Just to check my understanding: this would basically just be the
controller plane saying "inbound MPLS S-Label value <X> is an IP flow
with outbound interface and destination address <Y>", and no IP payloads
are inspected?

Section 7

[I will not repeat the comments from draft-ietf-detnet-mpls that are
also applicable here, but it seems that most of them are.]

There are perhaps some new bits where nodes at the IP/MPLS boundary are
tasked with enforcing the ingress filtering for the MPLS domain even
though both the IP domain and MPLS domain are part of the same DetNet
environment.  In some sense the duty to provide DetNet service and the
duty to protect the MPLS network could be in conflict, and we might want
to say something about how to handle that.

An egress T-PE that does not examine the IP headers might be susceptible
to attacks that generate spoofed IP traffic (and spoofed IP traffic is a
perennial annoyance in Internet environments, so contributing to it is
usually disrecommended).  Perhaps we should encourage at least
consistency checks on the IP headers with the configuration from the
controller plane for the IP flow in question?

Section 11.2

It is again surprising to see draft-ietf-detnet-data-plane-framework
listed as only an informative reference.

Erik Kline No Objection

Comment (2020-09-07 for -07)
[[ nits ]]

[ section 6 ]

* Perhaps "flow specific" -> "flow-specific"

* s/needed to provided/needed to provide/

* Perhaps "treatment needed to meet" -> "treatment to meet"
  (or s/needed/necessary/)

Murray Kucherawy No Objection

Comment (2020-09-07 for -07)
In the glossary, "L3" is specified, but it appears nowhere in this document.  Same with "PSN".  Nor does "PE", but "S-PE" does, yet it is not defined.

I concur with Barry's comments on references.

Warren Kumari No Objection

Comment (2020-09-09 for -07)
No email
send info
I agree with Alvaro -- there seems to be a lot of overlap between this and draft-ietf-detnet-mpls, and also "you can carry anything in MPLS" - I don't see what this document adds / does.

(Barry Leiba) No Objection

Comment (2020-09-03 for -07)
Just one small comment:

   This document uses the terminology and concepts established in the
   DetNet architecture [RFC8655] and
   [I-D.ietf-detnet-data-plane-framework], the reader is assumed to be
   familiar with these documents and their terminology.

I think this makes both of these normative, but the data-plane-framework draft is listed as informative.

Alvaro Retana No Objection

Comment (2020-09-08 for -07)
(1) I may have completely missed the point of this document; what is it?  More importantly, what is this document specifying?  Why is it on the Standards Track?

As I see it, this document says that IP flows can be carried over MPLS -- ok, specifically over DetNet MPLS.  The mapping of IP flows to an MPLS LSP is no different in DetNet MPLS when compared to "plain" MPLS...nor is it different for IP vs DetNet IP flows -- from §4.2:

   Mapping of IP to DetNet MPLS is similar for DetNet IP 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

At best, it seems to me that this document could be Informational.

(2) It looks like this document should be tagged in the Datatracker as (also) replacing draft-ietf-detnet-dp-sol-ip.

(3) s/both Non-DetNet and DetNet IP packet/both Non-DetNet and DetNet IP packets

Martin Vigoureux No Objection

Éric Vyncke No Objection

(Magnus Westerlund) No Objection

Robert Wilton No Objection

Comment (2020-09-10 for -07)

Thank you for this document.

FWIW, I think that this document should be PS rather than Informational, even if the core protocol specification part of it is very small, i.e. perhaps only sections 5 which is just one page long.  Possibly this could be have specified as part of the base detnet-mpls spec, but I also appreciate that it is arguably cleaner for it to be split into separate documents.