Reese- thank you for the thoughtful review. We have updated the draft based on your feedback. Please let us know if the latest revision addresses your concerns. A diff can be found here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-mops-treedn-04&url2=draft-ietf-mops-treedn-05&difftype=--html Further comments inline: On Wed, 1 May 2024, Reese Enghardt via Datatracker wrote: | | Reviewer: Reese Enghardt | Review result: Ready with Issues | | I am the assigned Gen-ART reviewer for this draft. The General Area | Review Team (Gen-ART) reviews all IETF documents being processed | by the IESG for the IETF Chair. Please treat these comments just | like any other last call comments. | | For more information, please see the FAQ at | | <https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!CNrNEPu4qRUMw3Af6GTBO7VT-huI-R0DP6h608nNh80rCEgCpAXjq7rsbFR-uOudwJJ0bn5t4ZJo5Q$ >. | | Document: draft-ietf-mops-treedn-04 | Reviewer: Reese Enghardt | Review Date: 2024-05-01 | IETF LC End Date: 2024-05-06 | IESG Telechat date: Not scheduled for a telechat | | Summary: The document presents a fairly clear and concise case study. To make | it more readable and useful, I suggest a few clarifications and tweaks in tone, | as well as adding a bit more content to the interesting points about the | multicast deployment issues. | | Major issues: None. | | Minor issues: | | Section 1: | "[…] while more efficiently utilizing network resources, and thus, improving | the experience of end users" Why does more efficiently utilizing network | resources improve the experience of end users? Please consider explicitly | stating any assumptions you are making, e.g., about bottleneck links. Noted that the assumption is based on the elimination of duplicated traffic. | | Section 3: | How do these reasons interact with RFC 9049, which lists obstacles to | deployment of path-aware networking techniques? Please consider reading Section | 4 of RFC 9049 and naming the lessons from RFC 9049 that apply to Multicast. | RFC9049 lists multicast as "future work" and I think it would be nice if this | draft could be considered the future work item for multicast, as the authors | appear to already have done the work of thinking through the deployment | obstacles. Thanks for the pointer to this doc. Added a ref to RFC9049 in sect 4.1. The past challenges noted in sect 3 are there to provide some brief background and context about the problems being solved with this architecture. This doc is not intended to be a comprehensive study of lessons learned about multicast deployment- and it's probably beyond the scope of the MOPS WG. Such analysis is better covered in https://datatracker.ietf.org/doc/draft-ietf-pim-multicast-lessons-learned/ | Section 4: | Please consider starting by saying that TreeDN can be either an overlay or a | "native on-net". Section 8 summarizes it well: "TreeDN is essentially the | synthesis of SSM plus overlay networking technologies like AMT." I think | stating this basic principle early on will make it much easier for the reader | to follow the rest of Section 4. | | "TreeDN leverages advances in the availability and understanding of overlay and | underlay networking." What specific advances does TreeDN leverage? Does it use | a new type of overlay different from previous overlays or underlays, or any new | techniques that weren't available in previous overlays? If not, please consider | rephrasing this text to explain in a more neutral tone that TreeDN leverages | overlay networks because they have certain advantages, or similar. Changed beginning of Sect 4 to: "TreeDN leverages a simplified model for multicast deployment combined with network overlays to deliver traffic to receiving hosts on unicast-only networks." | | Section 5: | | "[…] specialized CDN devices, which typically are servers that need to be | racked, powered and connected to revenue-generating ports on routers" I'm not | sure revenue-generating port is a widely understood term. Please consider | providing a brief explanation. Replaced with "and connected to ports on routers that could otherwise have been consumed by paying customers" | | "In this way, SPs can offer new RaaS functionality to content providers at | potentially zero additional cost in new equipment (modulo the additional | bandwidth consumption)." At face value, this text appears to be at odds with | the previous statement that TreeDN reduces bandwidth consumption. Please | consider rephrasing this text to make it clearer what is meant here. Good point. Rephrased to eliminate confusion. | | "Additionally, TreeDN is an open, standards-based architecture based on mature, | widely implemented protocols." The term "standard" has a specific meaning in | the IETF and refers to only RFCs published on the Standards Track, and not as | Experimental or Informational RFCs. While it appears that TreeDN can be | implemented based on specifications that are published as Standards-Track RFCs, | I'm not sure if TreeDN mandates that only Standards Track protocols can be | used, as opposed to Experimental or proprietary protocols. Please consider | rephrasing this text to clarify to what extent TreeDN is always based on IETF | standards. Removed "standards-based". | | Section 6: | "This reduces the cost for content sourcing […] By effectively reducing to zero | the marginal cost to the source of reaching each additional audience member" I | wonder if this text makes any implicit assumptions about the networks in which | content sources are located and about the interconnections and cost models used | by these networks. Please consider making these assumptions explicit. Explicitly noted this is from the perspective of the source. | | Section 7.2: | "Traditional unicast-based CDNs frequently rely on HTTPS over TCP transport" | Does this statement apply equally to QUIC, assuming we're not talking about MoQ | but simply replicating the existing unicast model using HTTP/3? If so, please | consider rephrasing this statement to be more generic and talk about HTTP in | general, independent of version. No, this statement applies to TCP, not QUIC. | | Nits/editorial comments: | | Section 3: | Please consider expanding PIM-SM and mLDP on first use. Added | | Section 4.2 | Please consider expanding GTM on first use. Added -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
