Ballot for draft-ietf-detnet-ip-over-mpls
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
[[ 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/)
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.
(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.
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.
(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 MPLS. 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
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.
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.
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. https://mailarchive.ietf.org/arch/msg/detnet/MNJKPDUR57nHMEkH9j2idywThRs/
Hi, 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. Regards, Rob