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

[Balázs Varga A <[e-mail]>]

Hi Benjamin,

Many thanks for the comments. My reactions/comments inline.

Thanks & Cheers 
Bala'zs

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: Thursday, September 10, 2020 8:22 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Ethan Grossman <[e-mail]>; [e-mail]
Subject: Benjamin Kaduk's Discuss on draft-ietf-detnet-ip-over-mpls-07: (with DISCUSS and COMMENT)

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).

<Bala'zs> OK. Thanks.

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).

<Bala'zs> OK. Thanks.

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?

<Bala'zs> Yes.

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.]

<Bala'zs> OK. I will check what to update based on those comments.

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.

<Bala'zs> OK. Policing on IP flows at ingress is part of protecting the network (and other DetNet flows as well).

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?

<Bala'zs> OK. Thanks.

Section 11.2

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

<Bala'zs> OK. Changed to normative.