[Last-Call] Re: [Mops] Genart last call review of draft-ietf-mops-treedn-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux