Hi, Remy, Regarding fragmentation, the explanation below is fine, but IMO should appear in the doc. It would be important to note that this *could* be a limitation for future PLC, even if it isn’t now (e.g., if data rate capabilities increase).
Joe > On Mar 4, 2021, at 8:13 PM, Liubing (Remy) <[email protected]> wrote: > > Hello Joseph, > > Thank you very much for your comments. Please see my reply below. > > Best regards, > Remy > > -----邮件原件----- > 发件人: Joseph Touch via Datatracker [mailto:[email protected]] > 发送时间: 2021年2月20日 9:15 > 收件人: [email protected] > 抄送: [email protected]; [email protected]; [email protected] > 主题: Tsvart last call review of draft-ietf-6lo-plc-05 > > Reviewer: Joseph Touch > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the > IETF discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > [email protected] if you reply to or forward this review. > > --- > > The only significant transport issue in this doc is the issue of MTU support. > Secs 3.3 and 4.6 refers to underlying frag/reassembly per RFC4944. First, > these sections seem redundant; normative requirements should appear in only > one section if both are retained. > [Remy]Thanks for indicating this redundancy. We will remove the reference of > RFC4944 in the section 3.3. > > More notably, the use of a 16-bit tag in that spec is already known to be > problematic for IPv4 fragmentation and could cause problems here as well, > e.g., per RFC4963. This issue should be addressed, notably if there is a > reason why a 16-bit tag is considered sufficient for this use it should be > stated or some other shim layer should be proposed with a more robust tag > (e.g., 32 bits). > [Remy]I think this question has already been discussed when RFC4944 was > defined. The situation shown in RFC 4963 "a host sending 1500-byte packets > with a 30-second maximum packet lifetime could send at only about 26 Mbps > before exceeding 65535 packets per packet lifetime" cannot be reached by the > constrained PLC networks discussed in this draft. Because the constrained PLC > networks are used for metering and other IOT use cases, in which the packet > is not that big, and the data rate is much lower, when compared to the "high > data rates networks" discussed in RFC4963. > > Some minor additional suggestions follow: > > The intro refers to “6lo”; this term should be defined before being used. The > scenarios should include a citation if available. Similarly, LLN should be > defined. Work that did not receive consensus might be mentioned elsewhere or > even omitted completely, but seems premature in the intro. Also, “the > previous work” in the last sentence is ambiguous; it would be useful to refer > to the RFCs, the draft, or whatever else to which it refers. > [Remy]We will extend the term, add citations to the scenarios in the intro, > and remove the reference to the work did not receive consensus. The previous > work refers to the [RFC4944], [RFC6282], [RFC6775] and [RFC8505]. We will > update it to a more specific description. > > Sec 3 includes “Moreover, recently a new …”, which seems redundant; it might > be just “A new…”. Again, this section (and later ones too) refers to “6lo” as > a category of sorts, which needs to be defined (and included in the > acronym/terminology list). > [Remy]We will update it in the next version. > > > > _______________________________________________ > Tsv-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tsv-art _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
