Deterministic Networking Architecture
draft-ietf-detnet-architecture-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-10-11
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-08-19
|
13 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2019-08-19
|
13 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Ron Bonica was marked no-response |
2019-07-31
|
13 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2019-07-26
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-07-07
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-19
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-05-14
|
13 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-05-13
|
13 | (System) | RFC Editor state changed to EDIT |
2019-05-13
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-13
|
13 | (System) | Announcement was received by RFC Editor |
2019-05-13
|
13 | (System) | IANA Action state changed to In Progress |
2019-05-13
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-05-13
|
13 | Cindy Morgan | IESG has approved the document |
2019-05-13
|
13 | Cindy Morgan | Closed "Approve" ballot |
2019-05-13
|
13 | Cindy Morgan | Ballot approval text was generated |
2019-05-13
|
13 | Cindy Morgan | Ballot writeup was changed |
2019-05-13
|
13 | Deborah Brungard | Ballot approval text was changed |
2019-05-13
|
13 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-05-10
|
13 | Alissa Cooper | [Ballot comment] Thanks for addressing my DISCUSS point. Old COMMENT left here: I support Benjamin's DISCUSS. I agree with others that this document should be … [Ballot comment] Thanks for addressing my DISCUSS point. Old COMMENT left here: I support Benjamin's DISCUSS. I agree with others that this document should be informational. = Section 3.1 = "There are, of course, simpler methods available (and employed, today) to achieve levels of latency and packet loss that are satisfactory for many applications." I think this paragraph would make more sense if it said "specific levels of latency and packet loss for particular applications." A lot of applications have satisfactory performance without any of the methods/techniques described. "Prioritization and over-provisioning is one such technique." It seems these are two techniques, not one. = Section 3.2.1.2 = s/sensitive/time-sensitive/ I can't parse this sentence: 'In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: o Sub-microsecond time synchronization among all source and destination end systems, and o Time-of-execution fields in the application packets.' = Section 3.2.2.2 = s/ Either of these functions/ Any of these functions/ "Providing sequencing information to the packets of a DetNet compound flow. This may be done by adding a sequence number or time stamp as part of DetNet, or may be inherent in the packet, e.g., in a higher layer protocol, or associated to other physical properties such as the precise time (and radio channel) of reception of the packet." How do multiple connected DetNet nodes know which fields they are supposed to use as the packet sequence number? = Section 3.3.1 = "the highest-priority non-DetNet packet is also ensured a worst-case latency." --> Did you mean "ensured less than or equal to a worst-case latency"? = Section 4.3.2 = If applications need to be altered to be run over DetNet, or if they need to be DetNet-aware, it would be useful to state that explicitly up front somewhere in this document. This is sort of implied in this section but it's not clear. = Section 6 = "However, the requirement for every (or almost every) node along the path of a DetNet flow to identify DetNet flows may present an additional attack surface for privacy, should the DetNet paradigm be found useful in broader environments." I'm not sure what is meant by "broader environments." Is the implication that flow identification doesn't present a privacy risk within a single administrative domain? I don't think that is always true. |
2019-05-10
|
13 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2019-05-06
|
13 | János Farkas | New version available: draft-ietf-detnet-architecture-13.txt |
2019-05-06
|
13 | (System) | New version approved |
2019-05-06
|
13 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2019-05-06
|
13 | János Farkas | Uploaded new revision |
2019-04-15
|
12 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss. One more minor comment: I see the reference to bufferbloat in section 3.2.1.1, however, I guess the reference … [Ballot comment] Thanks for addressing my discuss. One more minor comment: I see the reference to bufferbloat in section 3.2.1.1, however, I guess the reference would actually be even more need in section 3.3.2. I agree with Alexey and Benjamin that this document should be informational. Informational documents can also have IETF consensus, so that cannot be the reason to go for PS. However, this document does not specify a protocol or any requirements that are mandatory to implement for interoperability and therefore should not be PS. |
2019-04-15
|
12 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2019-03-25
|
12 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss point! The new security considerations section is well-written and quite well matched to an architecture document. |
2019-03-25
|
12 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-03-25
|
12 | Alvaro Retana | [Ballot comment] [Thank you for addressing my DISCUSS.] |
2019-03-25
|
12 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss |
2019-03-09
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-09
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-03-09
|
12 | János Farkas | New version available: draft-ietf-detnet-architecture-12.txt |
2019-03-09
|
12 | (System) | New version approved |
2019-03-09
|
12 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2019-03-09
|
12 | János Farkas | Uploaded new revision |
2019-02-21
|
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-02-21
|
11 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-02-21
|
11 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from No Record |
2019-02-21
|
11 | Suresh Krishnan | [Ballot comment] * Section 3.2.1.1. Given that we also know some of the downsides as well of large buffers, I think a pointer to some … [Ballot comment] * Section 3.2.1.1. Given that we also know some of the downsides as well of large buffers, I think a pointer to some background might be warranted here. I would recommend a basic reference to something like Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January 2012, * Section 3.2.2.2. It is not obvious to me how the POF cannot be the last operation at the receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see the need for them to do PRF and PEFs but I am not sure applying the POF at intermediate nodes can necessarily help the low latency and low jitter goals. The order in which a DetNet node applies PEF, POF, and PRF to a DetNet flow is implementation specific. * Section 3.2.3. RFC7426 does not contain much specific information about explicit route setup. Is there a particular section you want to point to. If not, I don't think this reference is of much use. RFC8453 is listed twice. * Section 3.3.1. Not sure why this is a requirement but I do wish to note that there are no such worst-case latency guarantees for best effort traffic (aka non-Detnet) in current networks. Can you clarify? o DetNet flows can be shaped or scheduled, in order to ensure that the highest-priority non-DetNet packet is also ensured a worst- case latency. * Section 4.1.1. This text "Peers with Duplicate elimination." seems to be completely out of place under the "Packet sequencing" heading below Figure 2. Copy and paste error? * Section 4.3.2. I found the expression "number of bit times" confusing. I have understood "bit time" to mean the amount of time taken to emit a bit from a network interface. Based on that definition, this expression does not make sense. Is there a better reference/definition of what you mean? * Section 4.5. There might be some other recent IETF defined mechanisms that might be relevant to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc. * Section 4.7.2. While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure what kind of mapping you were thinking for IPv4. If this is not possible, I think a note to that effect might be useful here. * Sections 5 and 6 I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and would like to see them addressed. |
2019-02-21
|
11 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-20
|
11 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-20
|
11 | Ben Campbell | [Ballot comment] I support Benjamin's and Alissa's DISCUSS positions. I also agree with the several people who commented that this should be informational. Otherwise, I … [Ballot comment] I support Benjamin's and Alissa's DISCUSS positions. I also agree with the several people who commented that this should be informational. Otherwise, I have some minor comments: §3.2.1.2, - first paragraph: Please expand "GigE" - "In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of:" - Hard to parse. §3.2.2.2: Please expand "PREOF" on first use. I realize readers can probably construct it from the previous few sentences, but it's more reader-friendly not to require them to do so. §3.3.2: "Robust real-time systems require to reduce the number of possible failures." - The sentence does not parse. Are there missing words prior to "to"? §4.1.2: - "Distinguishing the function of two DetNet data plane sub-layers, the DetNet service sub-layer and the DetNet forwarding sub-layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4." Hard to parse. Also, there is a comma splice. - "There are many valid options to create a data plane solution for DetNet traffic by selecting a technology approach for the DetNet service sub-layer and also selecting a technology approach for the DetNet forwarding sub-layer. There are a high number of valid combinations." Does this refer to implementation/deployment options, or protocol design options? If the latter, are the choices still open? §4.1.3: Please define or expand DetNet-UNI. §4.2.1, first paragraph: Does L1 stand for Layer-1, etc? If so, please spell it out. |
2019-02-20
|
11 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-02-20
|
11 | Warren Kumari | [Ballot comment] Thank you, this is a very well written, and easy to follow. I do have some minor comments and nits. 1: 3.2.1.2. Jitter … [Ballot comment] Thank you, this is a very well written, and easy to follow. I do have some minor comments and nits. 1: 3.2.1.2. Jitter Reduction "A core objective of DetNet is to enable the convergence of sensitive non-IP networks onto a common network infrastructure." You *do* say this in the introduction, etc, but this sentence is the clearest description - consider moving it up to the top. 2: 3.2.2. Service Protection "Service protection aims to mitigate or eliminate packet loss due to equipment failures, random media and/or memory faults." This talks about memory faults, but what about (the common case) of memory corruption? AFAICT, the protocol itself doesn't do anything about this - perhaps it should mention this, and say that strong checksums / integrity is the responsibility of the upper layer protocol? "Extraordinary claims require extraordinary evidence"- Carl Sagan. 3: "The DetNet service sub-layer includes the packet replication (PRF), the packet elimination (PEF), and the packet ordering functionality (POF) for use in DetNet edge, relay node, and end system packet processing. Either of these functions can be enabled in a DetNet edge node, relay node or end system." This says "either" about three things. 4: "3.3.2. Fault Mitigation Robust real-time systems require to reduce the number of possible failures." Apologies, I don't have suggested test to fix this, but "require to reduce" reads oddly -- perhaps "require a reduction in"? |
2019-02-20
|
11 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-02-20
|
11 | Alvaro Retana | [Ballot discuss] I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns about the coexistence with non-DetNet traffic and privacy: §3.3.1 talks about … [Ballot discuss] I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns about the coexistence with non-DetNet traffic and privacy: §3.3.1 talks about what I think is a hard to achieve balance between coexisting with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. Because of the constraints, the intent of prioritizing DetNet flows is clear (and that is ok), but that may result in starvation of non-DetNet traffic...even if the text does explicitly say that it "must be avoided". I would like to see the potential case of starving non-DetNet traffic called out somewhere. I'm looking for something similar to the first paragraph in §5, but focused on the non-DetNet traffic. Related to the above is the fact that the identification of flows could be used to specifically *not* include some of them as DetNet flows. This is a variation of the concern outlined in §6, but applied to non-DetNet flows, with the potential starvation mentioned above. Again, I would like to at least see some discussion of this risk. The use case and problem statement documents outline specific applications that may not have non-DetNet traffic, and the Introduction supports that. However, the architecture described in this document may be used in more general networks to provide guarantees to specific traffic... IOW, even if the intention is there, there is no guarantee that DetNet will only be used in the expected use cases. |
2019-02-20
|
11 | Alvaro Retana | [Ballot comment] I agree with and support Benjamin's DISCUSS -- also, I think that draft-ietf-detnet-security should be a Normative reference. I also agree that Informational … [Ballot comment] I agree with and support Benjamin's DISCUSS -- also, I think that draft-ietf-detnet-security should be a Normative reference. I also agree that Informational may be a better status. [nit] s/sub-layer at which A DetNet service/sub-layer at which a DetNet service [nit] Expand SRLG. |
2019-02-20
|
11 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2019-02-20
|
11 | Alissa Cooper | [Ballot discuss] = Section 6 = "DetNet is provides a Quality of Service (QoS), and as such, does not directly raise any new privacy … [Ballot discuss] = Section 6 = "DetNet is provides a Quality of Service (QoS), and as such, does not directly raise any new privacy considerations." This seems like a false statement given the possibility that DetNet may require novel flow IDs and OAM tags that create additional identification and correlation risk beyond existing fields used to support QoS today. |
2019-02-20
|
11 | Alissa Cooper | [Ballot comment] I support Benjamin's DISCUSS. I agree with others that this document should be informational. = Section 3.1 = "There are, of course, simpler … [Ballot comment] I support Benjamin's DISCUSS. I agree with others that this document should be informational. = Section 3.1 = "There are, of course, simpler methods available (and employed, today) to achieve levels of latency and packet loss that are satisfactory for many applications." I think this paragraph would make more sense if it said "specific levels of latency and packet loss for particular applications." A lot of applications have satisfactory performance without any of the methods/techniques described. "Prioritization and over-provisioning is one such technique." It seems these are two techniques, not one. = Section 3.2.1.2 = s/sensitive/time-sensitive/ I can't parse this sentence: 'In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: o Sub-microsecond time synchronization among all source and destination end systems, and o Time-of-execution fields in the application packets.' = Section 3.2.2.2 = s/ Either of these functions/ Any of these functions/ "Providing sequencing information to the packets of a DetNet compound flow. This may be done by adding a sequence number or time stamp as part of DetNet, or may be inherent in the packet, e.g., in a higher layer protocol, or associated to other physical properties such as the precise time (and radio channel) of reception of the packet." How do multiple connected DetNet nodes know which fields they are supposed to use as the packet sequence number? = Section 3.3.1 = "the highest-priority non-DetNet packet is also ensured a worst-case latency." --> Did you mean "ensured less than or equal to a worst-case latency"? = Section 4.3.2 = If applications need to be altered to be run over DetNet, or if they need to be DetNet-aware, it would be useful to state that explicitly up front somewhere in this document. This is sort of implied in this section but it's not clear. = Section 6 = "However, the requirement for every (or almost every) node along the path of a DetNet flow to identify DetNet flows may present an additional attack surface for privacy, should the DetNet paradigm be found useful in broader environments." I'm not sure what is meant by "broader environments." Is the implication that flow identification doesn't present a privacy risk within a single administrative domain? I don't think that is always true. |
2019-02-20
|
11 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2019-02-20
|
11 | Mirja Kühlewind | [Ballot discuss] Thanks for addressing the tsv-art review comments (and big thanks to Michael and David!) and all the work done so far! I think … [Ballot discuss] Thanks for addressing the tsv-art review comments (and big thanks to Michael and David!) and all the work done so far! I think the document is in good shape and I only have one minor comment that I would like to see addressed/more explicitly spelled out. However, this should be done quickly with potentially 2-3 small changes in the draft. See below. Given that DetNet traffic is often assumed to be not congestion controlled, it is important that there is also some network function that makes sure the source traffic stays within the requested bandwidth limit in-order to protect non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I think it should be more clearly spelled out that this would require a rate limiting function at each DetNet source/relay (tunnel ingress). Currently sec 3.3.2 says: "Filters and policers should be used in a DetNet network to detect if DetNet packets are received on the wrong interface, or at the wrong time, or in too great a volume." However, maybe this case of limiting non-congestion controlled traffic (in case the source in not keeping to the limits on purpose/in order to cheat, because it couldn't estimate the needed bandwidth requirement an better, or due to timely fluctuations) could be explained more clearing and the respective requirement to implement rate limiting could be state separately and more strongly...? One related comment on this sentence in Sec 3.1: "As DetNet provides allocated resources (including provisioned capacity) to DetNet flows the use of transport layer congestion control [RFC2914] by App-flows is explicitly not required." I guess congestion control should still be a requirement if the App-flow also passes not-DetNet-aware segments of the path, e.g. maybe the first hop. Usually use of congestion control for application limited flows is also not a problem if sufficient bandwidth is available. Also note that, as I stated above, the important part for not requiring congestion control is actually not only that resources are allocated but also that rate limiting is in place to make sure resources usage cannot be exceeded above the reserved allocation. Maybe this sentence could also be further clarified in the draft...? And then one more small comment that is also related. Sec 3.2.2.2 says: "If packet replication and elimination is used over paths with resource allocation (Section 3.2.1), ..." My assumption was that all DetNet traffic is send over pre-allocated resources...? If that is not true that has implication on congestion control and needs some additional considerations. Can you please confirm that and maybe clarify in the draft! Thanks! |
2019-02-20
|
11 | Mirja Kühlewind | [Ballot comment] I agree with Alexey and Benjamin that this document should be informational. Informational documents can also have IETF consensus, so that cannot be … [Ballot comment] I agree with Alexey and Benjamin that this document should be informational. Informational documents can also have IETF consensus, so that cannot be the reason to go for PS. However, this document does not specify a protocol or any requirements that are mandatory to implement for interoperability and therefore should not be PS. |
2019-02-20
|
11 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2019-02-19
|
11 | Benjamin Kaduk | [Ballot discuss] I note that the DETNET WG is explicitly chartered with a work item for the "overall architecture: This work encompasses ... and security … [Ballot discuss] I note that the DETNET WG is explicitly chartered with a work item for the "overall architecture: This work encompasses ... and security aspects". It seems incomplete to specify an architecture for a topic such as deterministic networking without specifically considering what threats are and are not in scope to be protected against. Some easy questions should be whether the system is expected to be robust in the face of an attacker that generates non-DetNet traffic? Or an attacker that generates DetNet traffic in excess of reservations? It can even be a fine engineering goal to produce a solution that only protects against media corruption and hardware crashes and leaves active attacks out of scope, but the actual intended scope of the work needs to be clear. At the other end of the spectrum, protecting against as potent an attacker as a malicious traffic policer is probably a lost cause, especially if the policer is authorized to direct remote nodes to take action to terminate "misbehaving" flows. The referenced draft-ietf-detnet-security is not at a comparable maturity level to this document and also fails to present a clear threat model for the DetNet architecture. (The section entitled "Threat Model" reads as more of a taxonomy of threats than a model for what threats are and are not to be addressed.) It also presents the usage of cryptographic mechanisms as mitigation techniques without provisioning for the prerequisties of such mechanisms (e.g., using HMAC for message integrity protection without mention of infrastructure for distributing the keys for keying the HMAC). |
2019-02-19
|
11 | Benjamin Kaduk | [Ballot comment] I agree with Alexey that Informational would (also) be a fine status in which to publish this document. Abstract … [Ballot comment] I agree with Alexey that Informational would (also) be a fine status in which to publish this document. Abstract DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). I don't know what "sub-network technologies" means. (Should I? Is it defined somewhere we can reference?) More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network" that lies between specific layers or classes of layer? Does DetNet itself have component "sub-layers" that provide distinct DetNet functionality? These are good questions to address early on in the document so the reader is familiar with the concepts as they progress through the document. Section 1 DetNet is for networks that are under a single administrative control or within a closed group of administrative control; these include campus-wide networks and private WANs. DetNet is not for large groups of domains such as the Internet. side note: Campus-wide networks at educational institutions are basically guaranteed to have untrusted entities participating in them, just as a backdrop for security considerations. Section 3.1 This mechanism distributes the contents of DetNet flows over multiple paths in time and/or space, so that the loss of some of the paths does need not cause the loss of any The failure models for which this statement is absolutely true as opposed to probabilistically true seem rather unrealistic models of real physical systems. Section 3.2.1.1 The primary means by which DetNet achieves its QoS assurances is to reduce, or even completely eliminate packet loss due to output packet contention within a DetNet node as a cause of packet loss. [...] editing error? Note that App-flows are generally not expected to be responsive to implicit [RFC2914] or explicit congestion notification [RFC3168]. I note that the word "implicit" does not appear in RFC 2914; it may be worth a bit more detailed of a mapping from concept to reference. (This text/reference also appears in Section 4.3.2.) Section 3.2.1.2 In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: It seems that an architecture would be within its rights to *mandate* such application design, rather than just encourage it. What sorts of exceptions would cause us to not want to mandate this design? Section 3.2.2.2 Please expand SRLG (it is only used once, so the abbreviation itself may not be needed at all). Section 3.2.3 Out-of-order packet delivery can be a side effect of distributing a single flow over multiple paths especially when there is a change from one path to another when combining the flow. [...] nit: comma before "especially". Resource allocation The DetNet forwarding sub-layer provides resource allocation. See Section 4.5. The actual queuing and shaping mechanisms are typically provided by underlying subnet, these can be nit: is this usage of "subnet" common? Also, this comma looks to be a comma splice. closely associated with the means of providing paths for DetNet flows, the path and the resource allocation are conflated in this figure. nit: Hmm, actually, is this comma *also* a comma splice? Operations, Administration, and Maintenance (OAM) leverages in-band and out-of-band signaling that validates whether the service is effectively obtained within QoS constraints. [...] nit: is there a singular/plural mismatch here ("the service"/"service" vs. "effectively within"/"effectively obtained within")? Section 4.1.1 This figure would have helped me a lot several sections earlier. Section 4.1.2 A "Deterministic Network" will be composed of DetNet enabled end systems, DetNet edge nodes, DetNet relay nodes and collectively deliver DetNet services. DetNet relay and edge nodes are Nit: I think this is intended to be: A "Deterministic Network" will be composed of DetNet-enabled end systems, DetNet edge nodes, and DetNet relay nodes, which collectively deliver DetNet services. DetNet relay and edge nodes are Examples of sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. [...] nit: are these sub-networks or protocols used by sub-networks? Distinguishing the function of two DetNet data plane sub-layers, the DetNet service sub-layer and the DetNet forwarding sub-layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4. This nit: this last comma is a comma splice. There are many valid options to create a data plane solution for DetNet traffic by selecting a technology approach for the DetNet service sub-layer and also selecting a technology approach for the DetNet forwarding sub-layer. There are a high number of valid combinations. nit: I think "large number" is more conventional prose. Section 4.3.1 I think I'm confused about how, for these flows that "require the feature", whether that means that the DetNet implementation must provide , or that it is required for the application to have implemented the feature. A mapping (if it makes sense) to the categorization of end systems in Section 4.2.1 would be a big help. Section 4.3.2 Asynchronous DetNet flows are characterized by: o A maximum packet size; o An observation interval; and o A maximum number of transmissions during that observation interval. Is there necessarily only a single tier of observation interval/rate? (E.g., could there be a burst cap in a small interval and then a lower overall baseline rate over large intervals?) That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is a rare event. (I might even go with "vanishingly rare".) Section 4.4.1 (Is there a standard reference for "Northbound"? I know we're all used to it, but it's probably best to have a reference if we can.) Section 4.4.2 The deterministic sequence can typically be more complex than a direct sequence and include redundancy path, with one or more packet replication and elimination points. [...] nit: "redundancy paths", plural? Section 4.8 How does *provisioning* require knowledge of *dynamic* state? Section 4.9 Does aggregation like this pose a risk of all the aggregatees getting affected when one exceeds their allocation substantially (so as to also cause the aggregate to exceed the aggregate's allocation)? Section 6 The ability for an attacker to use QoS markings as part of traffic correlation/inspection is not new with DetNet, but is probably still worth mentioning explicitly. |
2019-02-19
|
11 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-02-19
|
11 | Alexey Melnikov | [Ballot comment] Why is this document is not IETF Consensus Informational? |
2019-02-19
|
11 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2019-02-07
|
11 | Joel Halpern | Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2019-02-07
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2019-02-07
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2019-02-07
|
11 | Michael Scharf | Request for Telechat review by TSVART Completed: Ready. Reviewer: Michael Scharf. Sent review to list. |
2019-02-07
|
11 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Michael Scharf |
2019-02-07
|
11 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Michael Scharf |
2019-02-06
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-02-06
|
11 | János Farkas | New version available: draft-ietf-detnet-architecture-11.txt |
2019-02-06
|
11 | (System) | New version approved |
2019-02-06
|
11 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2019-02-06
|
11 | János Farkas | Uploaded new revision |
2019-02-05
|
10 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-05
|
10 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-05
|
10 | Deborah Brungard | Ballot has been issued |
2019-02-05
|
10 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-02-05
|
10 | Deborah Brungard | Created "Approve" ballot |
2019-02-05
|
10 | Deborah Brungard | Ballot writeup was changed |
2018-12-19
|
10 | János Farkas | New version available: draft-ietf-detnet-architecture-10.txt |
2018-12-19
|
10 | (System) | New version approved |
2018-12-19
|
10 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-12-19
|
10 | János Farkas | Uploaded new revision |
2018-10-22
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-10-22
|
09 | János Farkas | New version available: draft-ietf-detnet-architecture-09.txt |
2018-10-22
|
09 | (System) | New version approved |
2018-10-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-10-22
|
09 | János Farkas | Uploaded new revision |
2018-10-15
|
08 | Jonathan Hardwick | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Henning Rogge. Sent review to list. |
2018-10-03
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-09-28
|
08 | Michael Scharf | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Michael Scharf. Sent review to list. |
2018-09-27
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Scharf |
2018-09-27
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Scharf |
2018-09-27
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Dan Harkins. |
2018-09-25
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-09-25
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-detnet-architecture-08, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-detnet-architecture-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-09-21
|
08 | Joel Halpern | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list. |
2018-09-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2018-09-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2018-09-21
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Allison Mankin |
2018-09-21
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Allison Mankin |
2018-09-20
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2018-09-20
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2018-09-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2018-09-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2018-09-19
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-09-19
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-10-03): From: The IESG To: IETF-Announce CC: lberger@labn.net, db3546@att.com, detnet-chairs@ietf.org, draft-ietf-detnet-architecture@ietf.org, Lou … The following Last Call announcement was sent out (ends 2018-10-03): From: The IESG To: IETF-Announce CC: lberger@labn.net, db3546@att.com, detnet-chairs@ietf.org, draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Deterministic Networking Architecture) to Proposed Standard The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking Architecture' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-10-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides the overall Architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes (e.g., bridges or routers) along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 TSN. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2710/ |
2018-09-19
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-09-19
|
08 | Deborah Brungard | Last call was requested |
2018-09-19
|
08 | Deborah Brungard | Ballot approval text was generated |
2018-09-19
|
08 | Deborah Brungard | Ballot writeup was generated |
2018-09-19
|
08 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2018-09-19
|
08 | Deborah Brungard | Last call announcement was generated |
2018-09-19
|
08 | Deborah Brungard | Henning Rogge will do routing directorate review. |
2018-09-19
|
08 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2018-09-18
|
08 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2018-09-18
|
08 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2018-09-18
|
08 | Deborah Brungard | Requested Last Call review by RTGDIR |
2018-09-14
|
08 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. This version is dated 24 February 2012. > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Proposed standard > Why is this the proper type of RFC? This document has inter-IETF Areas and inter-SDO impact, most notably with IEEE, and having this document be an IETF consensus document is therefore considered highly important. > Is this type of RFC indicated in the title page header? Yes > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary > > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. > This document provides the overall Architecture for Deterministic Networking (DetNet) which provides a capability for the delivery of data flows with extremely low data loss rates and bounded latency. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 TSN. > Working Group Summary > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing particular worth noting. > Document Quality > > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? > The document is the foundation for other DetNet WG activities. It has been reviewed and discussed by many, including the WG technical advisor who is also TSV WG co-chair. Multiple organizations have stated that they are working on developing DetNet solutions and early solutions based on the principles described in this document have been demonstrated. > Personnel > > Who is the Document Shepherd? Lou Berger > Who is the Responsible Area Director? Deborah Brungard > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > I have reread this document as it progressed as well as in its final form. All significant technical comments were discussed publicly, some minor and more editorial comments were also provided privately. All identified comments have been addressed prior to publication request. The document is ready for publication. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No. > > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > The group felt that review from the TSV area was critical. WG discussion led to contacting the TSV AD and the appointment of the TSV WG co-chair as DetNet WG advisor. David reviewed this document and his comments were addressed prior to publication request. > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is uncomfortable > with certain parts of the document, or has concerns whether there really > is a need for it. In any event, if the WG has discussed those issues and > has indicated that it still wishes to advance the document, detail those > concerns here. No concerns. This document is critical to the WG and is ready to be published. > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. yes Authors/contributors know of none, see https://mailarchive.ietf.org/arch/msg/detnet/yI6xpBfDn_cSjuIHsiLOL9D33i8 > > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > There is an IPR disclosure from a non-wg participant on the pre-WG ID: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-detnet-architecture There were no concerns raised during WG acceptance of the document. > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? Very solid. The document is mature and has been discussed often. It was not published earlier in order to ensure the protocol solutions being defined in the WG would not necessitate any changes in the architecture. The solution work has progressed to the point that publications of this document makes sense. > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > N/A > (11) Identify any ID nits the Document Shepherd has found in this > document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. Only false warnings remain in the document. > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > N/A > (13) Have all references within this document been identified as > either normative or informative? > Yes > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? No, N/A. > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. No, N/A. > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. No, N/A. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC 5226). N/A > > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. None. > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > The only automated review was idnits. |
2018-09-14
|
08 | Lou Berger | Responsible AD changed to Deborah Brungard |
2018-09-14
|
08 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-09-14
|
08 | Lou Berger | IESG state changed to Publication Requested |
2018-09-14
|
08 | Lou Berger | IESG process started in state Publication Requested |
2018-09-14
|
08 | Lou Berger | Tag Doc Shepherd Follow-up Underway cleared. |
2018-09-14
|
08 | Lou Berger | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2018-09-14
|
08 | Lou Berger | Changed document writeup |
2018-09-12
|
08 | Norman Finn | New version available: draft-ietf-detnet-architecture-08.txt |
2018-09-12
|
08 | (System) | New version approved |
2018-09-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-09-12
|
08 | Norman Finn | Uploaded new revision |
2018-09-04
|
07 | Lou Berger | Changed consensus to Yes from Unknown |
2018-09-04
|
07 | Lou Berger | Intended Status changed to Proposed Standard from None |
2018-09-04
|
07 | Lou Berger | waiting for authors to confirm LC comments addressed |
2018-09-04
|
07 | Lou Berger | Tag Doc Shepherd Follow-up Underway set. |
2018-09-04
|
07 | Lou Berger | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2018-08-03
|
07 | János Farkas | New version available: draft-ietf-detnet-architecture-07.txt |
2018-08-03
|
07 | (System) | New version approved |
2018-08-03
|
07 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-08-03
|
07 | János Farkas | Uploaded new revision |
2018-06-28
|
06 | János Farkas | New version available: draft-ietf-detnet-architecture-06.txt |
2018-06-28
|
06 | (System) | New version approved |
2018-06-28
|
06 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-06-28
|
06 | János Farkas | Uploaded new revision |
2018-06-07
|
05 | Lou Berger | Notification list changed to Lou Berger <lberger@labn.net> |
2018-06-07
|
05 | Lou Berger | Document shepherd changed to Lou Berger |
2018-05-11
|
05 | Lou Berger | See https://mailarchive.ietf.org/arch/search/?email_list=detnet&q=architecture |
2018-05-11
|
05 | Lou Berger | IETF WG state changed to In WG Last Call from WG Document |
2018-05-01
|
05 | Norman Finn | New version available: draft-ietf-detnet-architecture-05.txt |
2018-05-01
|
05 | (System) | New version approved |
2018-05-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-05-01
|
05 | Norman Finn | Uploaded new revision |
2018-04-27
|
04 | Lou Berger | Pre WG LC IPR Call: https://mailarchive.ietf.org/arch/msg/detnet/yI6xpBfDn_cSjuIHsiLOL9D33i8 Final responses received: norman.finn@mail01.huawei.com: https://mailarchive.ietf.org/arch/msg/detnet/g-nb1O0NhQHOB0j3jW8Idn64pqQ pthubert@cisco.com: https://mailarchive.ietf.org/arch/msg/detnet/f60awIEIAUkCTLQv4eYoc_j8Whg balazs.a.varga@ericsson.com: https://mailarchive.ietf.org/arch/msg/detnet/cIVV9AOV2qLx1pOM3FfDZlhtujM janos.farkas@ericsson.com: https://mailarchive.ietf.org/arch/msg/detnet/9PmFcjeP6ok6fFG2nMWo0GGkB90 |
2018-04-13
|
04 | Lou Berger | Pre WG LC IPR Call: https://mailarchive.ietf.org/arch/msg/detnet/yI6xpBfDn_cSjuIHsiLOL9D33i8 Responses pending: norman.finn@mail01.huawei.com: pthubert@cisco.com: balazs.a.varga@ericsson.com: janos.farkas@ericsson.com: |
2018-03-05
|
05 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2018-03-05
|
05 | Norman Finn | Uploaded new revision |
2017-10-30
|
04 | Norman Finn | New version available: draft-ietf-detnet-architecture-04.txt |
2017-10-30
|
04 | (System) | New version approved |
2017-10-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2017-10-30
|
04 | Norman Finn | Uploaded new revision |
2017-08-08
|
03 | Norman Finn | New version available: draft-ietf-detnet-architecture-03.txt |
2017-08-08
|
03 | (System) | New version approved |
2017-08-08
|
03 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2017-08-08
|
03 | Norman Finn | Uploaded new revision |
2017-06-29
|
02 | Norman Finn | New version available: draft-ietf-detnet-architecture-02.txt |
2017-06-29
|
02 | (System) | New version approved |
2017-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Balazs Varga , Norman Finn , Janos Farkas |
2017-06-29
|
02 | Norman Finn | Uploaded new revision |
2017-03-13
|
01 | Pascal Thubert | New version available: draft-ietf-detnet-architecture-01.txt |
2017-03-13
|
01 | (System) | New version approved |
2017-03-13
|
01 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Norman Finn , detnet-chairs@ietf.org |
2017-03-13
|
01 | Pascal Thubert | Uploaded new revision |
2016-09-27
|
00 | Lou Berger | This document now replaces draft-finn-detnet-architecture instead of None |
2016-09-27
|
00 | Norman Finn | WG -00 approved |
2016-09-27
|
00 | Norman Finn | Uploaded new revision |
2016-09-27
|
00 | Norman Finn | Set submitter to "Norman Finn ", replaces to draft-finn-detnet-architecture and sent approval email to group chairs: detnet-chairs@ietf.org |
2016-09-27
|
00 | Norman Finn | New version available: draft-ietf-detnet-architecture-00.txt |