Re: [homenet] DNCP/HNCP Revisited

"Ray Hunter (v6ops)" <> Fri, 20 September 2019 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B1891200F4 for <>; Fri, 20 Sep 2019 04:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2bHk5dyHaWXz for <>; Fri, 20 Sep 2019 04:37:39 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f15:62e::2]) by (Postfix) with ESMTP id 5C53B1200D5 for <>; Fri, 20 Sep 2019 04:37:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 939C540195; Fri, 20 Sep 2019 13:37:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fCT73yb3jwXv; Fri, 20 Sep 2019 13:37:35 +0200 (CEST)
Received: from MacBook-Pro-3.local ( []) (Authenticated sender: by (Postfix) with ESMTPA id C5939400AD; Fri, 20 Sep 2019 13:37:35 +0200 (CEST)
To: Juliusz Chroboczek <>
References: <> <> <>
From: "Ray Hunter (v6ops)" <>
Message-ID: <>
Date: Fri, 20 Sep 2019 13:37:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------DED0710BAF932798FF7690A9"
Content-Language: en-US
Archived-At: <>
Subject: Re: [homenet] DNCP/HNCP Revisited
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2019 11:37:41 -0000

Thanks for your response.

Juliusz Chroboczek wrote on 20/09/2019 12:40:
>> 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.
A OK so you're saying this is already covered in (Section 4.4 of) 7787

   Upon receipt of:

    o  Request Network State TLV (Section 7.1.1 <>): The receiver MUST reply
       with a Network State TLV (Section 7.2.2 <>) and a Node State TLV
       (Section 7.2.3 <>) for each node data used to calculate the network
       state hash.  The Node State TLVs SHOULD NOT contain the optional
       node data part to avoid redundant transmission of node data,
       unless explicitly specified in the DNCP profile.

So what I was suggesting was merely additional clarification of that.

>> 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
> _______________________________________________
> homenet mailing list

So if I understand you correctly, you're saying this is the problem of 
the sender of the response to ensure UDP fragmentation doesn't break, 
and that multiple long UDP replies can be generated from a single query 
packet (potential amplification).

If there's multiple UDP replies required for a single query, would you 
expect sending of these individual packets to also be rate limited by 

What behavior would we expect from the requester during this time?
Wait for all outstanding replies to arrive?
Re-transmit a node TLV request for missing / dropped replies?