Re: [homenet] DNCP/HNCP Revisited

Juliusz Chroboczek <jch@irif.fr> Fri, 20 September 2019 10:40 UTC

Return-Path: <jch@irif.fr>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2512008D for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 03:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIzxBG3TtjeS for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 03:40:42 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B7E12001A for <homenet@ietf.org>; Fri, 20 Sep 2019 03:40:42 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x8KAebBI009110; Fri, 20 Sep 2019 12:40:37 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 29DF55D676; Fri, 20 Sep 2019 12:40:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5-FSZ0QvR39z; Fri, 20 Sep 2019 12:40:39 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F03AC5D670; Fri, 20 Sep 2019 12:40:38 +0200 (CEST)
Date: Fri, 20 Sep 2019 12:40:38 +0200
Message-ID: <874l17p7x5.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: RayH <v6ops@globis.net>
Cc: HOMENET <homenet@ietf.org>
In-Reply-To: <be600313-ed7b-40d5-b44a-92b38f9ada8c@email.android.com>
References: <87woe3vqbj.wl-jch@irif.fr> <be600313-ed7b-40d5-b44a-92b38f9ada8c@email.android.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 20 Sep 2019 12:40:37 +0200 (CEST)
X-Miltered: at korolev with ID 5D84ACA5.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D84ACA5.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5D84ACA5.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/B5HALjpODVgQWRyZ_Fd0xo2LxWU>
Subject: Re: [homenet] DNCP/HNCP Revisited
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 10:40:45 -0000

> 1) DNCP allows an option of whether a network state TLV contains optional
> nested payload (HNCP) TLV's or not.

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs.  An implementation may choose
to send them in the same packet, but they're independent TLVs and can be
sent in different packets.

> 2) The node requesting a node status TLV doesn't know in advance how big a
> reply packet will be generated.

> DNCP states that nodes MUST reply to all node status TLV queries.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

In other words, the only constraint is that every single node state TLV
must be sent in its entirety within a single packet.  As described in
a previous mail, this does bound the amount of data that a single node can
publish, but no bounds on the total size of the network.

> So requesting multiple node status TLV's in one packet could lead to an
> oversized UDP reply packet.

The replying node's behaviour has nothing to do with whether the requests
are aggregated in a single packet or not.  The replying node processes
each request independently, whether it finds them in a single packet or in
multiple packets.

-- Juliusz