[Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-ip-over-mpls-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-ip-over-mpls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-mpls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(Very much a "discuss discuss" -- I just want to make sure the conversation
happens, regardless of the outcome.)

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.