Re: [6lo] [Tsv-art] Tsvart last call review of draft-ietf-6lo-plc-05

Joseph Touch <> Fri, 05 March 2021 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E5FE3A0D7D; Fri, 5 Mar 2021 07:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.599, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WuHqLFedMGy3; Fri, 5 Mar 2021 07:45:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 835033A2290; Fri, 5 Mar 2021 07:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xHajdCDSzYWJg8b6j9sPJUHM6ZlKozDybKgOSnyFUVw=; b=box4vvpZ1Ylg4N7Q85sOK/efl tw13uZVjLHM1xHbfDG3+13Tg1GsP/6Vsex9mfs2PoVRE4b1DLhGPV7gcn4XQaTWD0uU9iWwczseKy WBNWi2qJj6tjftDwknwIHoa3dT35ibLvQHOBHp550Gk1/pK3GbeszPw8BuPX+xyEj3e3IAHEqOh94 9Ok6DXCREFxYiifkx3YVqT/E0kYbNygsxJbc67MXyjMh/TLNmxzpH9r0qb8jUT73qhrJECeOSLrz/ PxVLPQWAae+OS2Ozpbbomj/YjKC9X3hQEoAqgpDc8gxANz8Vg+2MYyBIAgCGF08hyAdW+NJjYDux6 s5f+r0Oow==;
Received: from ([]:55183 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1lICe2-001Boh-FO; Fri, 05 Mar 2021 10:45:43 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Fri, 5 Mar 2021 07:45:37 -0800
Cc: "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Liubing (Remy)" <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [6lo] [Tsv-art] Tsvart last call review of draft-ietf-6lo-plc-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Mar 2021 15:45:50 -0000

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).


> On Mar 4, 2021, at 8:13 PM, Liubing (Remy) <> wrote:
> Hello Joseph,
> Thank you very much for your comments. Please see my reply below.
> Best regards,
> Remy
> -----邮件原件-----
> 发件人: Joseph Touch via Datatracker [] 
> 发送时间: 2021年2月20日 9:15
> 收件人:
> 抄送:;;
> 主题: 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 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